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In this Issue 

;S£^^ Our cover subjects this month can barefy be seen in the cover photograph. 
~ They're the two tiny specks in the middle of the flat plate in the foreground. 
They are spheres of barium ferrite that serve as the frequency-sensitive 
elements of magnetically tunable bandpass filters for the millimeter-wave 
Wtt'^tti^tSM frequency range. (The millimeter-wave range is the region of the elec- 
^C^iM'm^ii^WM tromagnetic spectrum from about 30 to about 300 gigahertz, if s becoming 
more important as radar, communications, and other systems move to higher 
frequencies seeking higher performance or less crowding.) These filters are 
^HHAHB used as preselection filters in the HP 11974 Series preselected mixers, a 
family of four mixers designed for down-converting miili meter-wave signals from the 26.5-to-75- 
GHz range into the frequency range of compatible HP spectrum analyzers. The preseiection filter 
removes unwanted image and multiple responses, natural consequences of the mixing process, 
that clutter the spectrum analyzer dispfay and obscure the desired response. In the microwave 
frequency range, below 30 GHz, yttrium iron garnet (YIG) spheres have been used as resonators 
in such filters, but at higher frequencies, tuning magnets for YIG spheres begin to pose design 
problems, so a new material was needed. A new four-sphere filter design was also found necessary 
to achieve the required performance. The design and performance of the HP 11974 Series 
preselected mixers are deschbed in the article on page 49. The article on page 59 gives the 
reasons for the choice of scandium-doped, M-phase barium ferrite for this application and tells 
how the spheres are made. 

Software for computer integrated manufacturing (CIM) is in great demand, and HP development 
laboratories are responding with a steady stream of new products. Two are featured in this issue. 
The first, HP Interactive Visual Interface, or HP IVI, uses object-oriented design, the industry-stan- 
dard X Window System, and widget technology to help appfication software developers provide 
graphical user interfaces for industrial applications. (Widgets are standard pieces of software that 
produce pushbuttons, scrollbars, and the like on computer screens.) HP IVI improves its users' 
productivity in designing user interfaces because It is interactive, facilitates saving and reusing 
interfaces, and doesn't demand that users know the details of the X Window System or widgets. 
The article on page 6 gives an overview of HP IVI, which consists of two main parts. Users 
construct their interfaces using HP fVIs Interactive editor, described on page 32, and then activate 
the objects created with the editor by whting C-language programs using a toolkit of functions 
provided by HP ivrs application program interface. Details of the application program interface's 
object-oriented toolkit are in the article on page 11, and the design of the application program 
interface is the subject of the article on page 21. in the article on page 39, we're told how the 
HP IV! editor's own user interface was refined and given a 3D appearance with the help of a 
team of industrial designers. 

The other CIM software product In this issue is HP Device Interface System, or HP DIS. It 
addresses the problem of efficiently developing interfaces between computers and factory-floor 
devices like robots, programmable controllers, and machine tools. This Is a problem because 
these devices typically come from many manufacturers and have different, proprietary interfaces. 
HP DIS is a toolkit that helps application software developers create and test interfaces between 
HP 9000 computers and factory-fioor devices. Its development facility provides a high-level Ian- 
guage for specifying communications protocols. Its testing faciltty provides a test generator, a 
test exerciser, and a device simulator that makes it unnecessary to have actual devices to test 
interfaces. The HP DIS run-time facility executes protocols in real time. The design and perfor- 
mance of HP DIS are described in the articie on page 62. 
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Simulation is an important part of many design processes because It makes it possible to refine 
a design without actually building anything, provided that the computer model used for simulation 
accurately reflects the behavior of the device or system being designed. Engineers at HP's 
Colorado Integrated Circuits Division wanted to verify the accuracy of the electrical models of a 
408-lead multilayer ceramic package for a iarge integrated circuit chip. The models were made 
up of discrete inductances, capacitances, and resistances. To verify the models, these parameters 
had to be measured on a real package. When traditional high-frequency measurement methods 
proved inadequate, new methods were developed. These methods are the subject of the paper 
on page 73. 

In integrated circuit design, the objective of simulation is sometimes to predict, in the design 
phase, the statistica] distributions of a circuit s perfomiance parameters in production. A problem 
is that IC parameter variations aren1 all completely random, as they are assumed to be by 
commercially available circuit simulators. Those within a chip, such as side-by-side resistor values, 
are highly correlated, and failure to take this into account leads to inaccurate simulations. In the 
study reported in the paper on page 78, this problem was solved by applying principal component 
analysis, a branch of multivariate statistics. Each circuit parameter was expressed in tenns of a 
set of independent random variables. The independent variables were then used as the inputs 
to the circuit simulator program ^ and the results were later converted to circuit parameter data. 

Another application of simulation, this time to predict the pressure drop and air flow characteristics 
in a computer system processing unit, is described in the paper on page 82. In the past, these 
quantities have been determined from measurements on prototype machines, which are available 
only after most of the design has been done. If the measured results are unacceptable, major 
design changes may be required. The study showed that, using supercomputers and finite element 
modeling, it is possible to simulate the air flow accurately enough to allow meaningful decisions 
early in the design phase. 

R,P. Oolan 
Editor 

Cover 

The flat plate in the foreground is the iris plate from a magnetically tuned preselection filter 
used in the HP 1 1974 Series preselected mixers, (n the mtddfe of the plate are two tiny barium 
ferrite resonator spheres. Also shown are the top and bottom halves of the tuning magnet, the 
magnet body, and the two parts of the waveguide assembly. 



What's Ahead 

In the December issue, we'll have articles on the autochanger and servo design and system 
Integration of HP^s 20-Gbyte rewritable optical disk library system, designed for direct access 
secondary storage. Error correction, software protection, and system integration of HP's CD-ROM 
dhve will also be featured. The data communications and tormina! controller for HP 3000 computers 
running the MPE XL operating system now supports X.25 network packet assembler/dis- 
assemblers; two articles will deal with this capability. Well also have a research report on aniso- 
tropic dimensional changes in cold-drawn copper beryllium alloy as a result of aging. 
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An Overview of the HP Interactive Visual 
Interface 

The HP Interactive Visual Interface (HP IVI) prcduct uses 
object-criented and window technologies to provide 
Interactive and programmatic tools for building graphical 
user interfaces. 

by Roger K. Lau and Mark E. Thompson 



IN THIS AGE OF INFORMATION, creating effective user 
interfaces for industrial automation applications is a 
greater challenge than it has ever been. The right details 
from a vast array of information must be shown in the 
appropriate form to the Intended group of viewers. In ad- 
dition, the information that is communicated must be con- 
veyed in soch a manner as to enhance the decision making 
process. It often takes more time to develop the interface 
than it takes to develop any other part of an application. 
HP Interactive Visual Interface (HP IVI) is designed to help 
developers provide the tjrpe of user interface needed for 
industrial applications. 

HP IVI is a Liser-interface development tool built on the 
X Window System Version 11 and runs in the HP-UX 
operating system environment. It consists of two main 
parts: an interactive editor (HP IVIBuild] and an application 
program interface (API). Users construct their symbols and 
displays with HP IVIBuild (the builder) and write a C pro- 
gram using the API calls to call up and activate the windows 
and other objects created with the builder. An application's 
user interface can be constructed without the assistance of 
HP IVIBuild, but with it productivity is greatly increased 
by the ability to create the interface interactively. HP IVI 
is also one of the few products to combine at the builder 
level the power of a graphical presentation with the flexi- 
bility and interactivity of widgets [e.g., pushbuttons, 
scrollbars, and toggle buttons),^ 

This article describes some of the market research and 
the target customers for HP IVh and provides an overview 
of the two main components of HP IVI, HP IVIBuild and 
the application program interface. 

Market Research 

The main customers of HP IVI are software engineers 
who build industrial applications. This includes system 
integrators, independent software suppliers, and end users 
with internal .software engineering groups. These users 
benefit by being able to customize screens to their custom- 
ers* applications and by being able to reuse the symbols 
they created and saved in previous applications. HP I\^ 
also buffers its users from having to know the details of 
the intrinsics of both the X Window System and widgets. 
This is considered to be a benefit and a boost to productiv- 
ity. 

Market research indicates that manufacturing applica- 



tions require graphical user Interfaces, and the use of 
graphics on the factory floor is growing and being applied 
to monitoring production processes and data gathering. 
The requirements are performance, reliability, and the in- 
tegrity of data from a workcell. To satisfy these demands, 
the HP IVI product; 

■ Minimizes the user's expense for the development of 
user interfaces 

■ Provides a distributable user interface for improved cost , 
performance, and flexibility 

■ Offers windowing functions and dynamic data config- 
uration 

■ Integrates graphics and widgets ijitelligently 

■ Gives software engineers the productivity boost needed 
for them to remain competitive 

■ Ensures top performance and reliability 

» Gives the user full control over data from the factory floor 

■ Builds on standards. 

Early in the project, the HP IVI project team used a 
technique called quality function deployment (QFD] to 
help analyze customer needs in the industrial automation 
area. This research helped to define the features for HP 
IVI. The box on page 9 provides more information about 
QFD and its use by the HP IVt team. 

HP IVIBuild 

HP IVIBuild is the interactive window and symbol build- 

{coRtmu&d on page S) 
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Usef Interface Objects 
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API = Applieation Program Interface 

Fig, 1, HP IViBuiid /s used to cfGate user fnterface objects 
that are saved in a fife, and a user appiication uses the API 
functions to retneve and rnantputate the objects, 
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HP IVI Project Management 



The HP Jnteraci've Visual Jnienace project was a rejaiivety 
large software project (100 KNCSS) and as such it was taced 
witti some interesting challenges during proditct development 
Besides the normal challenges associated with software projeci 
management (e.g., versson control, code inspections, project 
Standards, and schedule deadlines), HP IVI was faced with tliree 
mam challenges: determining the exact customer needs belore 
design and imptementation. using enisting software, and using 
new software development technologies For determrning cus- 
tomer needs, a process called quality function deployment (QFD) 
was used. Tints process helped us to determine the featufe set 
for HP IVI (see bo>« on page 9) The exFSting software was a 
combination of software from other HP entities and from outside 
vendors. Fjnally, the new technologies included the use of ob|ects 
and windows tor design and rmplementation 

Existing Software 

One of the primary goals of HP IVI was to leverage the work 
of others. The decasion to use existing software resulted from the 
desire to decrease the time to market tor the product by reducing 
the engineering time and effort Envolved in design, implementa- 
tion, and support. There was also a need to base HP fVI on 
components that conform to standards (explicit or de facto). To 
these ends, the basic framework of HP IVi is based on software 
that was purchased as well as software that was produced by 
other entities in Hewlett-Packard. 

The HP IVI project team realized the benefits that could be 
obtained by leverage early on. The basic object-oriented 
framework, the error handling routines, the X1 1 client library and 
server, the X toolkit, and the HP X widget set were all the work 
of others. While we certainly achieved our goals of reducing 
design, implementation, and support costs, we missed our orig- 
inal time-to-markei goals. 

Following are some of the lessons we learned about leveraging 
existing software. 

■ The quality and stability of existing code is a critical factor. If 
there are many defects in this code, much time wifl be spent 
isolating the problem and negotiating with the software 
supplier to have it repaired This can wreak havoc with a project 
schedule. One way around this is to obtain the source code 
for the underlying software and make the repairs locally, This 
may provide the most timely solution, but also raises many 
support ability questions. 

■ Negotiating enhancements to the existing software may be 
difficult Priority lists may not mesh well between vendor and 
receiver Important enhancements in the underlying software 
may be delayed because of this 

■ Performance of a product may be adversely impacted by exist- 
ing software. If this is the case, lobbying for improvements 
may be time-consuming and marginally successful. 

■ Good documentation of existing software is essential for a 
product to be successful Inadequate or inaccurate documen- 
tation can also impact schedules, 

■ It is very important to establish a good line of communication 
and a strong working relationship with the existing software 
supplier Changes made to their product may have drastic 
effects on the local product, It is important to learn about 
changes as early as possible (i.e., at the investigation phase 
rather than at the release phase) 

Proiecl learns that leverage a large amount of software from 
other sources should be very careful not to assume that leverag- 



ing means wai less atTentton can oe pa; a [o prooucmg a very 
detailed design Leveraging software does not mean there is no 
cost associated watti tt Engineers have to learn and understand 
the code, design impacts must l3e assessed, and the leveraged 
code must be supported over the life of the product Also. 
leveraging product components does not automatically ensure 
a faster time to fnar1<e1. 

New Tecfinologies 

HP iVhs an ooiect-oriented system that is based on the widget 
technologies and the X Window System. Through the QFD pro- 
cess we found that building on a standard software platform is 
viewed as an important requirement by our target market. 

At the start of the HP IVI project no one on the team had any 
experience with object-oriented programming and design and 
only one person was familiar with wFndow systems. Therefore, 
we had to develop a process to disseminate technical information 
and promote technical expertise among the project team very 
quickly. This was accomplished through training, the exchange 
of information during design and code reviews, and the simple 
sharing of expertise among the project team 

The following observations come from our experience with 
object-oriented programming and design; 

■ Careful consideration should be given to mapping object 
classes to source code files The consequences can be fre- 
quent file access conflicts when changes are made to a tile. 

• The temptation to redo class hierarchies should be controlled. 
Developers must be careful to make practical choices on when 
the class hierarchies are sufficient. 

■ First-time users should not expect magic. We believe that there 
was a significant learning curve involved in our decision to 
use object-oriented programming and design 

• Once the learning curve is overcome, the object paradigm is 
a natural and productive one to use for developing software 
products 

■ Object-oriented programming and design have a lechntcal 
jargon that might mystify developers and their managers at 
first Therefore, familiarity with and consistent use of terminol- 
ogy must be established at the start ot the pro|ect. 

■ The object paradigm is not applicable to all software engineer- 
ing projects. Knowing when to reject this technology in favor 
of a procedure-based design is important. 

The use of multiple new technologies in a project with few 
team members having experience in any of these technologies 
does have its problems and can be a significant factor on the 
schedule because it is difficult to anticipate problems and avoid 
pitfalls However, using new technologies on a project can be a 
significant motivator to the engineehng staff Benefits and risks 
of the inclusion of new technology in any product development 
effort must be weighed carefully. 

Chuck Robinson 

Section Manager 
Industrial Applications Center 

Robin Ching 

Project Manager 
Industhal Applications Center 
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er of HP IVL It is an API application because it uses the 
HP IVI API library' of C functions to handle both the visual 
and the nonvisual aspects of creating objects such as man- 
aging object data structures and performing operations re- 
quired to manipulate objects. Consequently, the windows 
and models created and saved by the builder can be restored 
by an APJ program and vice versa (see Fig. 1), For the most 
productive use of HP IVI. the user first creates the windo^vs 
needed by an apphcation using HP IVIBuild and then 
mobilizes the created windows using a C program coniain- 
ing API functions. Fig- 2 shows an application user inter- 
face being created with HP IVIBuild. Although an entire 
HP IVI application could be written using just the API C 
functions, HP IVIBuild provides the following advantages 
over this method; 

■ No initial programming is required. 

■ The user can look at the user interface and manipulate 
it while creating it. 

■ The interface can be altered very quickly. 

■ Several graphical conveniences are available such a.s 
snapping to a grid and a simple method of creating ellipses. 

■ An API program that uses HP IVIBuild-created obiects 
is much simpler than one that creates the same objects 
from scratf:h. 

■ Symbols created in an HP IVIBuild session can be saved 
and reused. 

The articles on pages 32 and 39 provide more information 
about HP IVIBuild. 

Objects and API 

Since HP IVI is an object-oriented system, all operations 
are done with object s^ resulting in a system that is a hierar- 
chy of objects. Building this hierarchy starts with creating 




window objects (windows on the display) and then placing 
graphics and widget objects into the windows. To activate 
the objects in the window (i.e., give them dynamic proper- 
ties] some of the attributes of the objects can be changed 
[e.g., foreground or background color, visibility, or fill per- 
centage for a rectangle]. When an application uses objects 
to display data values, it can make calls to the API functions 
to update the data values In the objects displayed in the 
windows. 

The objects used in HP IVI are categorized into four 
hierarchical layers: 

■ High-Level Objects. These objects specify global attri- 
butes for die other levels of objects. This level includes 
the window and model objects mentioned earlier. 

■ Composite Objects. These are organizational groupings 
of primitive objects. This includes menus and their com- 
ponent menu panes> row-columns, and scroll lists. 

■ Primitive Objects. These are basic widgets and graphics 
objects — the basic visual pieces that make up the display. 
Graphics primitives include items such as polyNnes, 
splines, arcs, rectangles, and circles. Widget primitives 
include pushbuttons, toggle buttons, text widget s^ text- 
edit vxidgcts. menu buttons, and scrollbars Both tyi^es 
of primitive obiects can receive input from the user. 

■ Low- Level Objects. These are mostly nonvisual objects 
that are used to specify certain object attributes. Objects 
that handle object data structures and objects that handle 
events are examples of low-level objects, 

Because an object hierarchy is used^ displays can be 
created from the top down (parent to child) or the bottom 
up (child to parent), giving the designer a lot of flexibility 
in implementation. Certain objects can be gathered and 
arranged by making them into cliildren of composite oh- 

[cantinued on ps.ge lOJ 



Fig. 2, An application user inter- 
face being created using the in- 
teractive toois provided by HP 
tVIBufld. The too! box, utility box, 
and tine width panels ^re HP 
IVfBuHd components. 
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Quality Function Deployment and HP IVI 



Quality furict*on deployment (QFD) is an analylical method of 
colliding and analyzing sybj€Clive and ob|ectfve data about 
customer needs and wants It is one of the mettiods the HP IVI 
pro]ect team used to determine ttie minimum feature set required 
by our targei customers QFD was chosen because it faciii tales 
not only ihe translation of customer wants and needs into product 
features, but it also enforces consideralron of methods to smpfe- 
ment the features When the features are Known, the project 
schedule and required resources can be properly planned. Since 
our organization [HPs Industrial Application Center (I AC)) was 
new, ji was easy to promote QFD as a viable technique because 
there were no traditions ingrained in the organization. 

The QFD process is shown in Rg. 1 The first step is to coliect 
the customer needs data. To get this information we \^i sited many 
of the customers who represent our target marl^et, Tt)is took 
place over a penod of about rwo months. [AC teams of two or 
three members went out to each customer site. Taam personnel 
came from marketing, R&D, and management. These teams pre- 
sented a broadly defined, theoretical product to each customer 
focusing on how the product could make them more' successful. 
To get the spoken and latent needs out, a loosely structured, 
open-ended questionnaire was presented as an aid for generat- 
ing discussion, Motes were taken to record as much data as 
possible. The idea behind thjs technique was that some peopte 
don't state their feelings directly, They might say, "Forms based 
applications are good., if you have to use a terminal." But, what 
they really mean is, if given a choice, they wouldn't use a terminal 
at all for that application. 

Once the data was collected it was time for analyzing. We 
formed teams with people from the HP IVI project, marketing, 
and several people from outside I AC. Some of these peopte 
included learning and human factors specialists and a user inter- 
face developer from another division. One other person was our 
QFD consultant. 
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Customer r>eeds. whtch we called murmurs, wem categorized 
•nto groups based on some desired cuslomer feature related to 
issues such as ergoTX>mtcs or performance. When we tmisfied 
categorizing the murmurs, each murmur was ranKed into primary, 
secondary and tertiary needs Each of these rankings rep- 
resented a translation of cu stonier needs mto quanliffable tech- 
nical terms An example of customer murmurs and the rankings 
IS shown in Fig. 2. In most cases we had to derive the secondary 
or terriary need. From here the features were placed on a tree 
diagram to ensure that there were no gaps, and to guarantee 
that we had met all of our customer needs 

Duong data collection, each of the customer needs should be 
given an importance rating. However, our collectors had not 
been trained before going to the customers and so they did not 
collect the Importance rating with the murmurs. The team as- 
signed the ratings during analysis. 

The next step was to develop methods for delivering customer 
needs This was done with knowtedge of what could be done 
with software. These became our impiementalion methods For 
example, if a customer needed a window to display alarm infor- 
mation quickly, this translated into choosing a system thai could 
rapidly retrieve and display data in windows, such as the X Win- 
dow System 

Each implementation method was analyzed to determine if it 
had a strong, medium, or weak relationship to satisfying customer 
needs. This formed the relationship matrix (see Fig 3). Symbols 
are used in the matrix to indicate the relationship between cus- 
tomer needs and implementation methods If no symbol is placed 
on the matrix then the implementation has no relationship to 
satisfying customer needs, This graphic representation is very 
useful. One can look at the matrix and see the areas that cover 
the customer needs and the areas that require more attention 
because they have little or no coverage. This task is the most 
labor intensive portion of the QFD process. 

To get the features for the first and second release of HP IVI 
from the matrix, we assigned a number to each cell, For each 
feature we summed the cells to get an idea of how effective the 
feature would be at meeting the customer needs. We selected 
a cutoff value to determine the set of features that would bring 
us the most return for our investment in engineering time and 
effort. 

QFD proved to be an excellent tool for product definition. The 
feature set that was established (or HP IVI has generated much 
customer interest. One of the most significant benefits from Ihis 
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Fig. 2. A sampfe of customer needs ar}d wants (murmurs) 
ranked m primary, secondary, and tertiary order. 
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pracess was that because the engineering team was involved 

in ihis process, ihey emerged with a much better understanding 
of what the users really wanted. 
Knowing when to stop the QFD analysis is important. Unless 

specific goals and targets are set, overanalyzing can waste valu- 
able project time. Establishing a set o1 musts and wants to be 
accomplished wiih QFD, and drawing clear boundary lines early 
in the invesligatJon phase, helps keep ihe analysis from bogging 
down in too much detail. Also needed are tools to support the 
techntque. The HP IVI team did most otthe data analysts manually 



and as a consequence the data has not been updated as often 
as might have been done if the data could be manipulated elec- 
tron i call y. 



Mark Thompson 

Kent Chao 

Software Development Engineers 

fndustnal Application Center 



jects. Composite objects can be used to organize and add 
extra control over their descendant objects. For example, 
a row -column object can be used to organize different 
widget primitives into rows and columns. 

All objects in the hierarchy have attributes (e,g,H color, 
size, shading, etc.). It is through the control of these attri- 
butes that the displays created with HP IVI get their 
dynamic quality. One can easily manipulate several attri- 
butes on an object with a single API function call, changing 
location, color, visibility, or some other attribute. Other 
API function calls enable the developer to: 

■ Create and free objects 

■ Manipulate object attributes 

■ Save and restore objects 

■ Locate objects 

• Obtain user input from primitive objects 

• Perform visual updates of the display 

■ Manipulate lists of objef:ts. 

As an example ^ callback objects can be attached to any 
visual object and cause a callback function to be called 
whenever a predefined event (such as clicking on the 
mouse button or depressing a key on the keyboard) occurs. 
The callback function can be used to obtain and manipulate 
data frorn the shop floor and modify attributes of objects 



on the display (e.g., changing an object's color from green 
to red or changing tlie textual information displayed in an 
object). The API functions and the internal design of these 
functions are described in the articles on pages 11 and 21 . 

Conclusion 

HP IVI facilitates the design and implementation of one 
of the most important parts of any manufacturing applica- 
tion—its interface to the user. The benefits of the window- 
ing technology of Xll are just beginning to be realized on 
the manufacturing floor. HP IVI is one of the first integrated 
applications to bring the X Windows technology to the 
factor^'' floor. The combination of widgets and graphics 
gives the application designer more freedom to present the 
needed Information in the fashion best suited for its in- 
tended viewers. This design freedom promotes the kind of 
informed decision making needed in today's fast-paced 
and highly competitive industrial marketplace* 
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The HP IVI Object-Oriented Toolkit 

Using object-oriented design techniques, a minimum set 
of functions is provided with the l-IP IVI product for 
manipulating widgets and graphic objects to create a 
graphical user interface. 

by Mydung Thi Iran and David G. Wat hen 



THE HP IVI APPUCATION PROGRAM INTERFACE 
(API) is an object-oriented toolkit of C functions that 
enable a software developer to create an interactive 
and informative graphical user interface programmatically. 
The API functions can be nsed for any application in which 
a highly interactive graphical user interface is required* 
The collection of API functions provides tlie ability to build 
different models of user interfaces that can be saved and 
used again in other user interfaces. High-level objects pro- 
vide the control and organization necessary to support 
lower-Ieve! composite and primitive objects. All objects 
have configurable attributes or characteristics that make it 
possible to customize the look and feel of a particular ob- 
ject. Color, size, and font are a few examples of these attri- 
butes. The API functions allow a programmer to do things 
like create and free objects, query attributes, save and re- 
store objects ^ get input, and find objects by location. 

This article describes the the API functions and the arti- 
cle on page 21 describes the internal design supporting 
these functions. 



the display. There can only be one system object per appli- 
cation- All other objects (except low-level objects) are de- 
scendants of the system object. The direct descendant of a 
system object must be a server object, 

A server object is the interface to the display system. 
Information regarding the display and its physical charac- 
teristics is stored in this object, The server object establishes 
the link between the display device [an Xll ser\'er) and 
the user application (the client). Just like the system object, 
there can only be one server ob|ect per application. Win- 
dows are the only children of the server object. 

Window objects represent the drawable region of the 
display. A window is an area on a display that connects 
the world coordinate system (e.g., inches, nun, etc.) defined 
for a w^indow to the device coordinates (i.e-t pixels) of the 
display system. The window c£m be seen as a viewport 
into the world coordinate system. An application can have 
any number of windows. They can overlap one another 
and they can be manipulated using a window manager or 



The API Object Hierarchy 

All the components of an API application are separate 
objects that are combined together in a hierarchical arrange- 
ment to form a working user interface. An example of this 
hierarchical relationship is shown in Fig. 1 . This relation- 
ship is described in terms of ancestry. For instance, Model 
t2 in Fig. 1 is the parent of three children: Model 21, a rect- 
angle, and a row-column object. Another way of saying 
this is that Model 12 is the ancestor of three descendants: 
Model 21 ^ a rectangle, and a row -column object. 

Every API object belongs to one of four groups: high-level 
objects, composite objects, primitive objects, or low- level 
object.'i. Fig 2 lists the different API object groups. 
High-Levei Objects, These objects conlrol and organise 
groups of objects and hold global resources that help define 
other objects in the hierarchy. The high-level objects must 
be created in a specific order: system object, server object, 
window^ objects, and model objects. Before anything can 
be displayed, at least one of each of these objects must be 
available. Since these objects are required for every appli- 
cation, the API will create default high-level objects if they 
are not explicitly created. 

The system object is the highest object in the API object 
hierarchy. This objetjt stores globyl attributes that affect 
the input loop, the update pass, and global resources. The 
input loop is composed of the code that handles user input 
and an update pass is the process of flushing changes to 
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Fig» 1, The APf object hierarchy of a simple appfication. 
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the API functions. The last high-level object, the model 
object, is the only valid child of a window object. 

The model object allows an application to put composite, 
primitive, or other model objects into a single group or 
collection. When these objects are grouped together, func- 
tions can be performed on them as if they were a single 
object. At the same time, each part will retain its individu- 
ality. Models can represent a symbol or template that can 
be saved and restored as many times as desired. Models 
can have other models, composites, or primitive objects as 
children. 

Primitive Objects, These are basic visual objects that are 
part of one of two categories: graphic primitives or widget 
primitives. The graphic primitives are visual objects (e.g., 
circles, rectangles, and arcs] that can receive mouse input. 
An application can use these objects for graphically repre- 
senting user-oriented objects that display crucial informa- 
tion such as liquid levels and temperature. The widget 
primitives (e.g., pushbuttons, scrollbars, and text edits) are 
also visual objects. However, unlike the graphics primi- 
tives, widget primitives can receive keyboard input as well 
as mouse input. The widget primitives are used for display, 
text editing and input, and selection capabilities. Primitive 
objects have no children. 

Composite Objects. These objects provide the means to 
organize and manage other objects. Specifically, composite 
objects make it possible to group primitive wudget objects 
and other composite objects so that they can be manipu- 
lated as a single object. A function or attribute specified 
for a composite object affects its children without actually 
changing them. For example ^ erasing or redrawing a row- 
column object will cause all its children to be erased or 
redrawn automatically. 

Low -Level Objects. These are objects that are not directly 
visible like primitive or composite objects. They are stand- 
alone objects that are used to specify attribute values for 
primitive, composite, or high-level objects. Low-level ob- 
jects are used to set attributes for the other three object 
groups, apply API functions to a list of objects, or deal with 
user input from the activated objects. 



Polymorphism and API 

One of the key features of object -based systems is the 
concept of polymorphism. Polymorphism allows different 
objects to share a common operational interface [operations 
with the same name). When an operation is invoked, the 
function dynamically determines the object type and exe- 
cutes the appropriate code. Object-oriented programs are 
polymorphic because they can operate on many different 
object types with the .^ame functional interface. This com- 
mon interface provides a great deal of flexibility and ease 
of use to the API programmer. Common access reduces the 
number of functions and increases the power provided by 
the basic set of functions. 

The API functions provide the functionaUty of 
polymorphism through an identifier called Ztld. When an 
object is created via the ZtCreate functio^^ a Ztld is returned 
from the call for use in further operations. The Ztid is a 
pointer to the object that was just created. This handle 
allows the programmer to reference the object when addi- 
tional modifications are necessary. The API functions use 
this identifier to determine the type of object being manipu- 
lated. 

Attributes and Argiists 

Associated with API objects are attributes that describe 
properties of these objects. Examples of object attributes 
include properties that define appearance characteristics 
such as colors and fill patterns for graphic objects, and 
font, highlight area^ and 3D shadowing for widget objects. 
There are also coordinate system attributes that control the 
position and sizing of objects, including their point, heights 
width, scale, rotation, and translation. Table I lists the 
categories of API allributes. 

There is a specific list of attributes assigned to each API 
object type. Users can set these attributes to desired values 
or can query the values contained in them through a data 
structure called an Argiist. An Argiist is a variable-length array 
of attribute- value pairs. The following is the C structure 
declaration for an attribute-value pair, 

struct ZtArgLislStruct 
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ZtAttributeType ZtAttribute; 

ZtV a I u eTy pe Zt Va I u e ; 

}: 

typedef struct ZtArgUstStnjGt ZtArgListltem ; 

/* where: 

ZtAttribute is the deftned attribute 
ZtValueTy pe is defined as a pointer to a 

/" variable containing the attribute value 



7 
7 
7 
7 



Fig. 2. API object groups. 



Argiists are used to define attributes of objects or functions* 
Some of the advantages of using Argiists include: 

■ Argiists free users from fixed pararnsters in a function calL 
Tbe number of attributes that the user can pass as param- 
eters can vary. 

■ The number of function calls can be minimized by in- 
cluding multiple attributes in the Argltst as opposed to 
having lo use one function call per attribute change. 

■ Attributes can be initialized in the Argiist either statically 
or dynamically (at run time). 
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Table I 
Categortes of APf Attributes 

Category Description 

General Attribu tes that are com m o n t o mo st 

objects. Far example, the object 
name (ZtNAME). an object's visibility 
status (ZtVISIBLE). and user data 
(ZtUSEFLDATA). 



Coordinate System 



Trickle-Down 



Cdldr, Font, Raster 



Pattern and Line 



Widget Appearance 



Callback 



These are attributes tliat define: 

■ Si^e and position such as 
ail object's height and width 
(ZtHEIGHTand ZtWIDTH) 

■ T ran sf ormation , su ch as 

an object's rotation, scaling, and 
translation characteristics 
{ZtROTATE, ZtSCALE, 21TRANSLATE) 

■ Normalized device coor- 
dinates for placing windows 
(ZtXMIN , ZtXMAX, ZtYMIN , ZtYMAX) 

■ Aspect ratio of window 
device coordinates (Zt AD JUST, 
ZtXADJUST ZtYADJUST] 

■ As fleet ra t i os of server objects 
(ZtXPIXELS,ZtYPIXELS). 

Attributes that affect the 
descendants of objects 
(ZtVISIBLE, ZtSENS*TIVE), 

Attributes that specify the 
object's color, fontn or raster. 

■ Raster I ists [Zt RASTER. LIST) 

■ An object's color [e.j?., ZtBACK- 
GROUND_COLOR, ZtFORE- 
GROUND_COLOR,etc.} 

■ An object's fonl (ZtFONT) 

■ An object's raster (e.g.. Zf FILL 
RASTER. ZtlCON_RASTER] . 

Attributes that control the 
appearance of borders . li nes . and 
fills (e.g., ZtFILL„TILE, ZlBACK- 
QROUND.TILE, ZtLINE.WIDTH). 

Attributes that define a widget's 
appearance [e.g., ZtSHADOW, 
ZlBOTTOM_SHADOW COLOR. 
ZtTOP^SHADOW. COLOR). 

Attributes used to attach user- 
defined functions to an object. 
These functions are used to 
respond to user input. For 
exam p 1 e , Zt R E ASON s p ec 1 f i es 
when a callback function should 
be called, and ZC AL LB AC KL FUNC- 
TION specifies a function for 
processing user Input. 



Parenting 



Keyboard Traversal 



Function 



Attributes that affect or define 
the current API object hierarchy 
(e.g.- ZtCHILD_UST» ZlCURREhFT. 
MODEL). 

Attributes that assign the input 
focus to an object (e.g. . ZtTRA- 
VERSAl, ZlNEXT_TOP_WrNDOW). 

Attributes that affect the capa- 
bilities of functions [e,g..ZtRE- 
CURSIVE. ZtMERGE). 



API Functions 

Because of polymorphism a minimum number of API 
functions are required for manipulating API objects. 
Polymorphism allows the same API function to be used to 
handle more than one object. Table 11 shows the API func- 
tions available for manipulating the object groups shown 
in Fig. 2. 



Table fl 
Categories of API Functions 



Function Use 



Function Nam.es 



Create and Free Objects ZtClone, ZtCreate, ZtCreateList, 
ZtFree 

Mani pulateAttributes ZtChang ©^ ZtQuery 

Save and Restore Objects ZtSave, ZtRestore 

Locate Objects ZtFindBy Attribute, ZtFind By Location 

Receive Input ZtDo(.,,ZtlNPUT.,.) 

Perform Visual Updates ZtOo(;..ZtDRAW.„) 
ZtDo(..,ZtERASE..O 
ZtDo(,.,ZtFLASH.O 
ZtDo(...ZtLOWER,..) 
ZtOo(.,ZtRAISE,.} 
ZtDot...ZtREORAW,.0 
ZlDo(.,,ZtUPDATE,..) 



Manipulate Lists 



Manipulate Arglists 



ZtCheckLpstObject, ZtCountUst. 
ZtQetListlndex, ZtGetListOt»ject< 
ZtGetUslTail. ZtlnsertListJndex, 
ZtlnsertListObject,ZtlnserlL(stTaJI, 
ZtMe rgeListI n d ex . ZtM e rge Li stTa i J , 
ZiMergeListObiect.ZtRemoveLJstlndeK, 
Zt Re mo ve List Object. Zt Rem o veLf slTai I » 
ZtRepf ace List I ndex , ZtRepf aceListOb j ect , 
ZtReplaceListTaiJ 

ZtFreeArgList 
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Create and Free Objects 

Objects are created using the function ZtCneate. Any attri- 
butes that are required to be different from the defaults can 
be passed In the object ArgUst when calling ZtCreate, For all 
the attributes not included in the object ArgList, the API will 
automatically set them to defaults- Once an object exists, 
multiple copies of this object can be made by cloning it 
with the function ZtClone. ZtCJane also allows the users to 
alter some of the attributes of the newly cloned objects in 
the same calL 

The following example shows the creation of tw^o text 
objects with one fixed size, different text strings, and differ- 
ent positions on the display. Fig. 3 shows the data organi- 
zation resulting from this example, 

intretum_vaj; 

Ztlcfte)rt1_ld,text2_ld,pointld; /* object identifiers V 

/* arglist for text object (contairiing attribLit&- value pairs) •/ 

static REAL64 h. w; 

static ZtArgLislltem text Argils! [ ] ^ 



Text Objects fZ!TEXT_oejj 



ZtHEIGHT. 


(ZtVaiueType)&h, r 


text height 


V 


ZIWIDTH. 


(ZtValueT/pe)&w. r 


text width 


V 


ZtPOINT, 


{2tVafueType)NULL, r 


Ztid for point 


•/ 


ZtSTRiNG. 


(ZtValueType)NULL, r 


textsthng 


7 



NULL, (ZlValu©Tvpe)NULL 

}: 

/* arglist tor point object 

static flEAL64 x, y: 

static ZtAfgUstllem pointArgiist [ ] = 

{ 

ZXX, (2tValueType)&x. 

ZtY. (ZtValueType)&y. 

NULL, {2tValu^Typ«)NULL ; 



lBKt1_ld 



Point Objects 
{ztPOtNT_oej) 




texts^ld 




Fig. 3. Data organrzation for text objects created with the 
function ZtCreate Or ZtCton^. 



intreturn_val; 

ZtId text 1 _ Id. text2_ld, pointld; >'' object identifiers'/ 

/* argi ist for text object {contai ni ng attribute- val ue parrs */ 

The text A rg iist an d the po f nt 
Arglist are tJne same as in the 
previous ex ample. 

r arglrst for cion ed text object ?/ 

static ZtArg Li St Item clone Arglist [] = 



I 



ZtPOINT, (ZtValueType)NULL, 
ZtSTRING, (ZtValueType)NULL, 
NULL. (ZtVaJueType)NULL 



r create ref erenc e point for objects 
x= 10.0;y = 10.0; 
pointld = ZtCreate{ZtPOINT_OBJ,poinlArg[ist, NULL); 



The reference points and the first 
text object are c re ated the same as 
in the previous exampke. 



r setup to create first text object with height = 20 and '/ 

r width - 40 V 

h -20.0;w = 40.0; 

textArglist[2].ZtValue = (ZlValueType) pointld; 

textArgfist[3].ZtValue - (ZtValueType) 'First text object"; 
/* create the f i rst text object */ 

textl_ld - ZtCreate (ZtTEXT^OBJ.textArgNst, NULL); 
r ch ange poi nt compon e nts •/ 

y - 60.0: 

retum_val - ZtChange(pointld. pointArglist, NULL); 



/* create the second text object at (1 0,60) using the V 

r ZtClone function 7 

y = 60.0; 

return_wal ^ ZtChange (pointld, pointArglist, NULL): 
don e A rg I ist[OJ Zt Valu e = (Zt Value Type)poi ntld : 
cloneArglist[i].ZtValue = (ZtValueType) "Second text object" 



text2Jd ^ 2!tCfone(Text1Jd,cloneArglist, 

NULL); 



/' create second text object at ( 1 .0 , 60 . 0) */ 

textArgNstl3].ZtVa!ue = (ZtValueType ) ' ' Second text object' ' ; 
texta^ld - ZtCreate (ZtTEXT^OBJ.textArglist, NULL); 



r free poi nt object ff it is no longer n ceded 
ZtFree (pointld, NULL); 



V 



Instead of calling ZtCreate twice, the function ZtCtone can be 
used to create the second text string object: 



r free point object if it is no longer needed V 

ZtFree (pointld, NULL); 

ZtClone is particularly useful for models nnd composite 
objects. With one call, the model or the composite object 
and its descendants can be duplicated. A call to ZtClone can 
be modified to control the depth of cloning for a list of 
obiects. In the following example there are two model oh- 
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jects that have identical properties excepi for the back- 
ground and foregroiind colors. The first model object has 
been created with the child list model 1 1d. Instead of repeating 
the same process for the second model modeEld, ZtClone is 
used with the function Afglist containing the ZtRECURSIVE 
attribute set to TRUE. The call ZtCtiange(} changes the colors. 

jfitfeLval: 

ZtId modell Id, modei2ld: 
* objectArg I i si for co I ors ' 
static ZtArgLismemcolorArglfst [] = 

( 

ZtBACKGROUND_COLOB,(ZtValueType)red, 

ZtFOREGROUNDCOL0R,(ZtValueType)b]adc, 

NULU(ZtVaJueType)NULL 



functtonAfglist for recursive attribute 



static ZfArgLislltemrecursiveArg list [] - 

{ 

ZtRECURSlVEJZfVaiueType)TRUE, 
NULL,(ZtValueType)NULL 



modet2lci ^ ZtCtone(moden Id, NULL, recursiveArglist); 
reLval = ZlC^Tange(fnodel2ld,coforArglist. 
recursiveArgNst); 

Cloning nonrecursively (ZtRECURSIVE = FALSE] can he 
used in cases where objects need to be referenced but copies 
of these objects are Bot needed. Fig. 4 shows the data struc- 
ture that would result after noiu'ecursively cloning the ob- 
jects referenced by the linked list called Usti, Instead of 
copying the iibjects, a new linked list iList2) of pointers is 
created for referencing the objects. The original and newly 
cloned list will dereference the same objects. HP IVIBuildt 
the Iniiltler component of HP I VI, makes use of this option 
of ZtClone to duplicate lists of selected objects. The cloned 
lists are manipulated through the tise of list functions to 
provide the undo and backup capabilities of HPlVlBuild (see 
page 36). 

When an object is no longer needed, the function ZtFree 
can be used to free all memory allocated for the object. 
Arglists can also be freed usln^the function ZtFree Arg List: This 
function wuU free all memory associated with the Arglist 
including the additional memory allocated for attributes. 

Manipulate Attributes 

Most attributes of existing objects can be modified. For 
example, in an application in which a text object contains 
a string that indicates elapsed time, the time needs to be 
updated periodically. ZtChange can be called passing the 
new value of the elapsed lime in the ZtSTRING attribute of 
the object Arglist, 

ZtChartge also provides a way to modify several objects 
in one calb The user simply has to put all the desired 
objects into a list and issue a ZtChange call on the lisl f^bjecl. 
The changes will be made to all objects that the list refer- 
ences. In the following code fragment the foreground color 



is changed for all objects referenced by the identifier fistld. 

' arglist for foreground cotoc */ 
static ZtArg List Item fgcArglfet f 1 = 



ZtFOREGR0UrstD_COLOR, 
NULL. 



(ZtV33ueType)NULL, 
(ZtVaiueType)lSiULL 



tnt retum_val; 

fgcArg[rst[0],Zt Value - (ZtValueType) steel blue 
r Steelb^ue is the index into the system object s color lisl 
r (theZtCOLOR_LISTattnbute on theZtSYSTEM_OBJ). 
' change the color to steelblue 

return. val ^ ZlChange (Jisttd. fgcArglist. NULL); 



V 
f 



Default values can also be changed ivith the same call. 
To change the value of a default attribute, the object type 
and not the object Id must be sent to ZtChange. For instance, 
if at some point in the program it is desired to have all the 
windows have a red background instead of the default bluet 
a call could be made to ZtChange with the object type set 
to ZtWtNDOW.OBJ instead of the objectld. 

Information about the current value of an object's attri- 
butes or the default values can be obtained by making use 
of the ZiQuery call. Ef required, API will handle the space 
allocation for tiie queried values. The following code frag- 
ment is requesting information on a pushbutton object. 

int return. vai; 
char 'query str; 

■ argiist tor querying strtng */ 

static ZtArgLfstltem qstringArglist [ 1 = 



ZtLA8EL_STRING, 
NULL, 



[ZtValueTvpe)NULL. 
(ZtValueType)NULL 



/* 
/' 



A copy of the pushbutton Id's label siring will be returned inquerystr */ 
after the ZtOuery call. A return vaJue of FALSE indicates that 7 

memory could not be allocated or an invalid pointer Is 7 

specified in pu sh button Id. */ 

retum_val = ZtQuery (pushbuttonid, qstringArglist, NULL); 

querystr=[char^)qstrtngArgllst|0].Zt Value; 
the following call frees the memory allocated for ZttnAaEL^STR ING *•' 
in the ZtQuery calf. V 

Zt Free A rg Li sl(q stri ng Arg ii st ) : 



Save and Retrieve Objects 

Ibe ztSave function allows users to save objects in a file. 



List 1 




List a — ►. 



Fig, 4. Ctoning lists of objects nonrecursively . 
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A filename can be specified by the user In the function 
Arglisl. If the file exists, the user also has Ihf; option to 
overwrite the existing file. Objects or defauHs of one appli- 
cation can he retrieved easily in another application witli 
the ZtRestore call. In the following example the window 
windowld is saved into a file named wmdfile.w* 

int r©tum_va!; 

2t!d windowld 

/' filename argtist V 

static ZtArgListltem saueArg1ist( ] ^ 



{ 



ZtFILENAME, 

ZIOVERWRITE. 

NULL. 



(Zt ValueTy pe)' ' wi ndfi ie . w'\ 

(ZIValueType)TRUE. 

(2tValueType)NULL 



retum_val = ZtSave (windowld, saveArglist) 

Locate Objects 

the capability of locating the closest object near a user- 
defined point in a window is provided by the function 
ZtFmd By Location. Users can control the aperture of the search 
[i.e,, how cluse or how far from the point) and the depth 
of the search (i.e.. wfietfier or not the action should be 
recursively applied down to primitive objects within any 
model or composite object). For example, a row-column 
object contains a pushbutton object, a text object, and a 
scrollbar object. A mouse click (i,e., a button event) gener- 
ated on the pushbutton will cause Zt Find By Location to return 
the Zild of the pushhulton if the function Arglist contains the 
value TRUE fur I he ZtRECURSIVE attribute. If ZtRECURSIVE is 
set to FALSE, the return value rjf ZtFindByLocation will be the 
Ztid of the row-column object instead of the pushbutton 
(see Fig. 5). 

Zt Find By Attribute also enablestheuserto match objects that 
have cerlahi pruperties. For example, if an application 
create.9 a large number of objects imd some of them are 
invisible, to find all the invisible objects, theZtFindByAttribute 
function is used on the window object, passing an object 
Arglist with the ZtVISIBLE attribute set to FALSE. 



/* redraw aN objects w heth er o r not they h ave been mod ff f ed */ 

ZtOo[systemld,ZtREDRAW, NULL); 

' draw a window T 

ZtDo[Wfndowld, ZtUPDATE, NULL); 

/" fiash art object on ttie display ^: 

ZtDo(pushbutlonld,ZtFLASH,NULL); 

/ ■ f i as h tti e obj ects o n a 1 1 st ^' 

ZtDo(listld,ZtFLASH, NULL): 

, ' erase a rectangle object W' 

ZtDo{rectang(eld, ZtERASE, NULL); 

/* erase a list ot objects ^ 

ZtDo(listld, ZtERASE, NULL); 

f" draw a text object whether o r not it h as been mod if i ed */ 

ZtDoftextld.ZtDRAW, NULL); 

I * draw a list ot objects other ttian tow-tevel objects 7 

ZtDo(Jistld, ZtDRAW, NULL); 

'* raise a window 7 

ZtDo( windowld, ZtHAISE, NULL); 

/* lower a window 7 

ZtDo( windowld. ZtLOWER, NULL); 

Two modes of updating or drawing objects on the display 
are possible: immediate update and deferred update. In 
immediate update mode the window^s are redrawn <3nylime 
there is a visual change in the objects- In the deferred mode, 
the process of redrawing windows can be postponed until 
an explicit update is performed throughZtDot ...ZtUPDATE...), 
or a change in the update mode. This mode is useful if 
changes need to be made to many objects and it is only 
necessary to refresh the window^ once. Both modes are 
activated by setting the system object's update attribute to 
either immediate or deferred. The following code puts the 
system object in the deferred update mode. 

/" update mode arglist for system object */ 
static ZtArgListltem updateMode Arglist [ ] = 
\ 

ZtDEFER_UPDATE.(ZtValLjeType)TRUE, 

NULL, (ZtValLieType)NULL 

}; 

ZtId systemld^ window id; 

int return_val; 



Receive Input Functions 

Input events like button and key firesses can be collected 
using the function ZtDo(Objectld. ZtlNPUT. NULL). Where object- 
Id is the ZtId of a system object and ZtlNPUT is the action for 
ZtDo to do. The input-handling ZtDo function retrieves the 
events and dispatches them to the appropriate callback 
function so that the user-defined action can be executed. 
User input can be collected continuously or in a single pass. 



Mouse Event 


(rawcoJumn^d) 








J. _ _. 










' Puih^ulton 
X 


I .„ I 
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(pusttbuttontd) 


ttextUd^ 




(sirrolFbarld) 



Visual Update Functions 

In addition to getting input, ZtCto provides several other 
actions. It provides the capabilities to update, draw, re- 
draw, flash, erase, raise, and lower objecLs on the display. 
The following is a list of the different operations possible 
with the ZtDo function. 



ZtHECUHSIVE 



FALSE 
TRUE 



ZtJd HetUfned from Zi Finds yLocadoFi 



rowcolumnfd 

pus h bull an td 



Fig. 5. Locating an object with ZtFindByLocation. When a 
mouse event happens over the pushbutton, if the ziRECURSIVE 
attnbute {$ false the identifier for the row-column object 
frowoolumnld/ ;s returned, if the ZtRECURSIVE attnbute is TRUE, 
the function searches for the primitive object in the area and 
returns the identifier for the pushbutton (pushbuttonid;. 
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at some point in the appJicaiion, set update mode to deferred 
refejm^val = ZtChange (systemid, updateModeArglist NULL): 



' now it IS necessary to redraw one of the windows */ 
return.val = ZlDo (windowtd. ZtUPDATE, NULL): 

List Manipulation Functions 

The API list manipuJation functioiis allow programiners 
to create anii manipulate lists of objects. 
Creatmg an Object List, The following example creates a 
list of two paints using the function ZtCreateList (see Fig. 6). 

r arglist for point object */ 

static REAL64 x, y; 

static ZtArgListltem pointArgltstl ] = 

{ 

ZtX, (ZtValueType)&x. 
ZtY, (ZtValueType)&y. 
NULL, (ZtValueType)ISlULL 



K 



•/ 



•/ 



r Identifiers for pointer objects 
Ztid point ltd, point2!d, pointjts!; 
•*[dentifEers for pointer objects 
r create a point at (50.0,50.0) 7 

X = 50.0. y = 50.0: 

pointlld = ZtCreale (ZtPOiNT_OBJ, pomlArglist, NULL); 
/• create another point at (60,0^50.0) '.' 

X - 60.0; 

point2td = ZtCreate (ZtPOlNT_OBJ, pointArglist. NULL): 
create the list for these two points '■ 

poinLlist = ZtCreateList (ZtLIST^OBJ, pointlld, pointSld. NULL); 



/' 



Freeing a List* When the list of objects is no longer needed, 
it can be freed. The application has the option to free the 
list along wilh all the objects it references, or to free the 
list but retain the objects, 

/* free the potnt list (poinLlist) in the exampfe above '/ 

Int relurn„vai: 

static ZtArgListltem recursive Arglist [ ] = 

f 

ZtRECURSIVE. (ZtValueType)TRUE, 
NULL. (ZlVaJueType)NULL 

r free the list and its references, the two point objects 7 
recurstveArglist[01 ZtVaiue - (ZtVafueType)TRUE; 
return. val - ZtFree(point Jist, recursiveArgiist); 

r free the list but leave the two point objects aione */ 
recursiveArglist[Ol.Zt Value = {ZtValueType)FALSE; 
return^vat = ZtFree(point_1ist, recursiveArglfst); 

Bookeeping, Three API functions are provided for retriev- 
ing information about list objects. These functions include: 

■ ZtCheckListObject for verifying the presence or absence of 
an object in a list. 

■ ZtCountList for counting the number of objects in a list. 

■ ztGetUstindex for determining the position of an object 



in a list. 
Extraction. An object can be extracted from a list of objects 
by invoking ZtGetystObject and specif\ang the index of the 
object, or by using the function ZtGetUstTail to extract the 
last object in a list. 
Insertian, Objects can be inserted into a list by using: 

■ ZlJnsertListtndex to place the object at a specified index 

■ ZtlnsertListObjecl to place the object before an object with 
a known identifier 

■ ZtlnsertListTail to place the object at the end of a list. 
These functions can be used to add an object to the child 

lists of windows, models, or composite objects. The follow- 
ing code fragments demonstrate using these functions. Figs. 
7a and 7h show the results of the ZtlnsertListlndex and the 
ZtlnserUjstObject examples respectively. 

r insert an object at location two in list pointLJstld *f 
Ztld pointListld, point 1 td, newpointUstld. Insertpointld, refpointJd, 

pointid; 
int ret: 

r poinlLlstId : the ZtId of a ZtLlST_OBJ to insert the object into */ 

r pointi Id : the ZtId of the object to insert into the list V 

r newpointListId: the ZtId of the new list If the function */ 

r fails, the original pointListld is returned */ 

/* in newpointUstld. If the function succeeds, 7 

f the new list is returned in newpointListid. 

obj index =2: 

ret = ZtlnsertList3ndex{pointUstld, obj Index, point lid, 
&newpointListld): 



/* insert an object (insertpointid) into a list (pointListld) */ 
r in front of another object (retpointid) 

ret = ZllnsertUstObjectipointListld. refpointld, 
Insertpointld.&newpointListld) : 



/* add a point object (pointid) to the end of a point list V 

/• (pointListld) '^ 

ret - Z!lnseftlJstTail(pointListld, point Id, atnewpointListId); 
Merging Lists. A list of objects can be merged into another 



poiFitlIri 



polnl._ll5l 




Fig. 6. Dafa orgamzetion idostrating a Hst of two points 
created with the tunciion ZtCrealeList 
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list by using: 

■ ZtMergeLlstlndex to place the list at a specified index 

■ ZtMergeListObject to place the list before an object with a 
known identifier 

■ ZtMergeLJstTaN to place the list at the end of a list. 

In the following example three objects of type ZtLIST_OBJ 
are used to illustrate merging lists. Listld references three 
objects [objectlld, object2ld, object3id), Mergefd references two 
objects (objecl4ld and objectSId), anti Newiistld is the list object 
obtained by merging Ustid and Merge Id [see Fig. 8). 

/' Using ZtMergeListfnde;< to Insert alE objects of Merge id 7 
/' Ento Listfd between object 1 id and object21d ^' 
Ztid Listld, Mergeld, Newristtd: 

int reLvaJ; 

INT32 lisUndex - 1 ; 

rei_val -^ ZtMergeListlndex(Listtd. list^index, Merge id, 
SNewltstld); 
/* Using ZtMergeListObjecl to insert all objects of Mergeld Into '/ 
r Listld in front of object21d 7 

Ztid Listld, Mergeld, NewlJslld, object2ld; int ret^vai; 
ret_val - Zt Me rgeListObject( Listld, object2ld, Merge Id, 
&NewlJ5tld); 



Removing Lists* Objects can he removed from a list by 
using: 

■ ZiRemoveLSstfndex to remove an object at a specified index 

■ ZtRemoveListObject to remove an object before an object 
with a known identifier 

■ ZlRemoveUstTaiC to remove an object at the end of a list. 
Children of windows, models, or composite objects can 

be deleted by invoking these functions on the list object 
specified in the ZtCHILD_LIST attribute. 

ReplacemenL An ohjec:t can replace another ohfect using: 

■ ZtReplaceListtndex to place the object at a specified index 

■ ZtReplaceListObject to place the object before an object with 
a known identifier 

• ZtReplaceListTail to place the object at the end of a list, 

r replace a point object at the index position of a point 7 

/• list (pointUstld) with a new point object (newpointlD) V 

r pointUstld : the Zttd of a ZtLIST.OBJ to replace the V 

/* object in 7 

/* newpointid : the ZtId of the object to replace the indexed 7 

r object with 7 

/* replaced Id : the ZtId of the replaced object. This variable 
may be given as NULL if this return value is 

not of interest. */ 



objindev 



Indexes 



pain LLI slid 



m 



pclnlLi^stld 




tnsertpo^ntfd 



m 



Fig. 7, (a) Insemng the object 
pointid in the list pointUstfd at index 
2. (t>) Inserttng the object insert- 
pdntid into the (ml pomtUstld in front 
of the object refpoimid. 
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21ld poimListId, replaced Id. newporntld, 
irfr32 objindex = 2: 
irti ret; 

re? = ZtReplaceListlrKtexfpolntUstId, objlntiex, newpoirrtid, 
&repfacedld|: 

* Ttie next aide fragment rllustrams using ZlReptaceListOt^ec! *' 

* The object identifiers have the folfowing meanings: 

"* poirrtUstld : same as abova 7 

" p<iinL_index_ld; the Zfid of ttie objec! to replace '/ 

' newpoiotld : the Zild of the object to replace pointJndexJd '/ 

" replaced Id : same as above */ 

ret = ZtReplaceListObject(poin1Uslld, point^indexjd, 
newpointid, replacedid); 

r replace the taiJ object of a point list (pointListld) */ 

/* with a new point object (newporntid) 7 

ret - ZtReplaceListTaiKpointUstId, newpointid, &replacedld): 

Grouping and Reparenting Objects 

Using the methods and techniques described so far. ob- 
jects can be created and grouped together to form an object 
hierarchy hke the one shown in Fig* 1 . This is accompUshed 
using model objects or composite objects. Model objects 
allow an application to group together composite objects, 
primitive objects, and other model objects into one group. 
They are invisible contamer objects and they do not own 
any visual attributes. Composite objects have visual attri- 
butes and they make it possible to group together primitive 
widget objects and olJier composite objects. Examples of 
composite objects include menus, menu panes, row-col- 
umns, and scroll lists. There are tw^o ways of creating model 
or composite objects in API; creating objects with the child 
list attribute (2tCHILD_LIST), or assigning a group of objects 
to another parent. 



Creating Composites with ztCHiLDAlsl 

Using ZtCHILD.LlST, model and composite objects and 
their descendants can be created either lop do^vn or bottom 
up. 

Top Down* The composite object is created with NULL as- 
signed to the child list attribute ZiCHILD_UST. It then be- 
comes the current composite object and all newly created 
primitive objects will automatically become the compos- 
ite*s children. For example, to create a menu system from 
the top to the bottom, start from the top of the menu hierar- 
chy and work down creating children. This process is sum- 
marized in the followmg steps: 

■ Create the menu object Z!MEWU_OBJ with the ZtCHILD_LIST 
attribute set to NULL. This will make the menu the current 
composite object. 

■ Create a menu pane object ztMENUPANE_OBJ. This will 
make the menu pane a child of the menu object and also 
make it the current composite object. 

■ Create the menu button objects. This will make the menu 
buttons children of the menu pane, 

" Change the attribute ZtCUBRENT_COMPOSITE on the sys- 
tem object [ZtSYSTEM„OBJ| to the menu object created in 
the first step. This will make the menu the parent of the 
next menu pane. 

■ Repeat the last three steps until all the menu panes and 
menu buttons are created. 

Bottom Up, To create a composite object from the bottom 
np, create all primitive objects, put them in a list, and then 
create the composite object setting the ZtCHILD_LJST attribute 
to the Zttd of the object list. For example, to create a menu 
system from the bottom up, start from the bottom of the 
menu object hierarchy t making the newly created objects 
children of objects higher in the menu hierarchy. This pro- 
cess is summariised in the following steps. 

■ Create a group of menu buttons and put them in a list 
object ZILIST_09J. 

■ Create a menu pane with the ZtCHILD_LIST attribute set 
to the Ztid of the ZtLlST^OBJ created in the first step. 



lUlefgeld ► 




Ustid 



^^1.^ 



objectUd 



Db(ecl2ld 



ob|&c^l3id 



MewJtSLtct 






otxiecti Id 



{ibject4ld 



C]b)ect5ld 



objectSId 



obiecaid 



Fig. a. Merging lists. The objects 
on list Merge Id are merged be- 
Iweer^ the first and second objects 
of iist bstid resuitfng in a new iisi 
Nevwiistid 
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■ Repeat ihe first two steps yntii all the menu panes and 

menu buttons are created- 
" Put all the menu panes into a list object. 
• Create the menu object with the ZtCHILD.LIST attribute 

set to the newly created ZtLIST^OBJ from the previous 

step, 

Repareniing 

hi API it is not necessary to destroy all the objects created 
and start all over when the user wants to change the objects' 
relationships. Regrouping objects by changing relation- 
ships is called re parenting. The ZtChange function maices 
thti ta.sk of regrouping very easy. The new child list Is 
simply passed to the desired parent object, and the API 
takes care of removing the targeted children from the old 
parent's c:hild list and assigning them to I he new parent. 
For example, the fallowing code segment moves the 
pushbutton object PushButton i from Model 2 to Model 1. and 
inserts PushButton 1 into the child list of Model 1. 



ZMdpbiid: 
Ztldmodehid; 
ZtfdchiJdlisllId; 
INT32ret; 



PushButton 1 Id V 
Model 1 1d "/ 
ModeH childlisl •/ 
Return Value V 



Freeing Model or Composite Objects 

The counterpart of cloning model and composite objects 
recursively or nun recursively is the ability to free these 
objects from the intermediate parent. Take the case of an 
application in which one of its model objects has a row- 
column object as o\m of its children. Suppose the applica- 
tion requires that the row^-column nhject be heed, but the 
children of the row-column object must remain. The API 
provides an option in the ZtFree function that allows the 
user to accomplish this task. Setting the ZtRECURSIVE attri- 
bute in the function Arglist to FALSE, and calling ZIFree on 
the row-column object, destroys the row-column object, 
and its childrtjn become the children of the model object, 
hi contrast, passing a function Arglist to ztFree with ZtRECUR- 
SIVE set to TRUE will free the row-coiumn object and its 
children. 

Symbols and Models 

Models can be created as children of other models, A 
model within another model is called a .submodel. For 
example, in Fig. 1. Model 21 is a submodel of Mode] 12. The 
user can create a symbol library out of submodels. Cus- 
tomised sets of commonly used symbols can be created* 
saved, and reused as submodels. 



static ZtArgListltem child! istArgtist [ ] = 



ZtCHILD_LlST, (ZtVatueType)NULL. 
NULL, (ZtValueType)NULL 



h 



r get the current child fist of Model 1 */ 

ret - ZtQu e ry f model 1 1d , ch i Id li stArg list, NU LL) ; 
If (ret) 



{ 



chtldlistlld = (Ztid) childiistArgiistlOl.ZtValue; 



/• add pushbutton pb1ld to the end of the child list of modei 1 '/ 
ret - ZtJnsertUstTail (chiidlrstlld, pblld, 

Sichildlistl Id); 
If (ret) 

r Change madel lid's childlist to include the pushbutton pblld V 
/* The API automatically updates the child list of model 2 "/ 

ret = ZtChange ( model 1 1d, childiistArglisl. NULL); 
) 



Conclusion 

Based on an object-oriented frameworks the API consists 
of a simplified yet powerful set of functions for creating 
and activating user interface components. The application 
developer can learn to use these routines within a short 
time. The developer is also able to combine the dynamic 
animation capabilities of graphics and the flexibility and 
interactive capabilities of widgets to enhance user inter- 
faces for process control applications. Models of physical 
objects such as machinery and instrumentation can be 
created to provide context-specific information that the 
end user can react to more quickly than with a standard 
terminal -oriented mterface- 
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HP IVI Application Program Interface 
Design 

To provide the features available in HP IVI, the interna! 
design and implementation of the application program 
interface leveraged concepts and software from graphics 
packages, window technotogy, widgets, Xt Intrinsics, and 
object-oriented design. 

by Pamela W. Munsch, Warren L Otsuka, and Gary D. Thomsen 



ONE OF THE MAIN goals of the HP Interactive Vis- 
ual interface [HP IVi] project was to leverage fea- 
tuies from current user interface and software de- 
sign technologies and blend the best of each into the feature 
set and design of the application program interface [AFT] 
functions. In doing so, the project team investigated win- 
dowing, graphics, the X toolkit [Xt Intrinsics), widgets, and 
object-oriented design* This article discusses the features 
used from each of these technologies, and how these fea- 
tures are incorporated into the interna I design and im- 
plementation of the API functions [see Fig. l). 

Windowing 

To hide the complexities of the X Window System^ '^ 
from HP IVI application developers, the API provides a 
layer of simplifying software over X. The only X features 
left exposed are those tliat we thought the application de- 
veloper must have access to, or that cannot be layered over. 
Even with this layer of software, the user still has access 
to X functions. For example, X provides an event called 
ConflgufeNotify that tells the application that a window has 
been resized, moved, or changed in some way. The API 
handles resizing the window object when this event occurs 
but lets the application decide if all the objects in the win- 
dow should be resized to match the new window's size, 
or if the objects should maintain their sizes and only the 
coordinate system of the window should be adjusted. The 
user still has direct access to the X functions if they are 
needed. 

The API also ensures that all X events (e.g., a mouse 
button press and release] that occur in a window object 
are sent to the application. This is done through callback 
techniques based on the Xt callback mechanism. There are 
also mechanisms and data structures to provide a linkage 
between X event data formats and API data formats. 

Graphics 

Most graphics packages, such as Hewlett-Packard's Star- 
base graphics package,'* provide coordinate systems that 
allow users to write device independent graphics programs. 
Since creating a user interface with the X Window System 
is currently done using pixels, the API project team decided 
to provide API functions that enable user-interface design- 
ers the same type of device independent coordinate system 



features as offered by Starbase. 

Graphics packages provide coordinate systems that: 

m Communicate with a particular device (device coordi- 
nates) 

■ Provide display resolution independence [normalized 
or virtual device coordinates) 

■ Allow the user to work in a system that reflects their 
world (world coordinates) 

■ Allow users to move, scale, or rotate images easily with- 
out recalculating the placement and size of the image 
(model i ng tran sformationsj. 

Device coordinates (DCs) are the coordinates used to 
write to a device. For the X Wuidow System, device coor- 
dinates are defined in pixels. 

Virtual device or normalized device coordinates (NDCs) 
provide a means to gain independence from the re.solution 
of the display. This coordinate system maps the width and 
height of a display to the coordinate range from 0,0 to 1.0. 
Normalized device coordinates define a viewport. A view- 
port is a rectangular drawing region on the display surface. 
Specifying the viewport in NDCs maintains the ratio be- 
tween the drawing area and the display size regardless of 
the display resolution. 

World coordinates provide a user-defined coordinate 
system. This system allows users to create pictures using 
the most appropriate coordinate system for the task. For 
example, if the world coordinates represent the physical 
dimensions of a factory ^ using the dimensions from a blue- 
print of the factory to create a picture is straightforward. 
World coordinates define which area of the unbounded 
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world coordinate space is visible in the viewport* This type 
of coordinate system also provides viewport-size indepen- 
dence and display-resolution Independence since the 
world coordinates remain the same regardless of the phys- 
ical size or resolution of iHr display. 

Modeling transformations allow the user to define a 
slightly different view of the world coordinates for each 
piece of the picture. Modeling transformations are geomet- 
ric transformations such as scaling, rotation, and transla- 
tion (movement]. This feature allows the user to draw an 
object and then reuse it in ihe picture by movingt scaling* 
and rotating it to fit the requirements of the picture. 

These three coordinate systems and the modeling trans- 
formations are linked together when an object is drawn, 
Fir.st, the object is transformed by its modeling transforma- 
tions to the desired orientation in the world coordinate 
system. The worJd coordinates are scaled and translated 
to fit into the viewport and converted to normalized device 
coordinates* Finally the normalized device coordinates are 
converted to device coordinates to draw the picture in the 
viewport. These transformations are shown in Fig. 2. 

Widgets and Xt Intrinslcs 

The widgets [pushbuttons, scrollbars, etc.) and the Xt 
Intrinsics provide the basis for the API input model and 
for other API features. The API project team took the input 
loop from Xt Intrinsics and added processing to handle 
API graphics objects. Also leveraged from the Xt Intrinsics 
are the methods for getting file descriptor input and time- 
outs. An extension of the Xt callback technique allows 
users to attach functions to window objects to handle X 
events and to API graphic objects, which include geometric 
figures such as circles, arcs, and rectangles* to handle 
mouse button events. 

To keep the number of API functions low, API parameter 
handling is patterned after Xt Intrinsic Arg lists. The API 
ArgJEsts are arrays of aUribute and value pairs. This feature 
frees the application from having fixed parameter lists that 
force it to make many calls. The application also doesn't 
have to pass unnecessary parameters. Parameters that it 
doesn't pays are automatically defaulted. One deviation 
from the Xt Intrinsic Arglist is that the API uses a null-termi- 
nated list instead of a counted list- The API also extends 
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Fig. 3. The Xt Intrinsics XtMainLoop function. 

the attrihute default concept so that the application can 
change the defaults of different classes of objects at run 
time. API Arglists are described in the article on page 11. 

Object-Oriented Design 

HP IVl is an object-oriented system. Object-oriented de- 
sign and objecl -oriented programming are being increas- 
ingly used at HP for software product development."*'^ The 
goals of object-oriented methods are very appealing be- 
cause ihey encourage such practices as code reuse and 
functional cohesion of software components [objects). 
Also, once a stable and reliable library of objects is avail- 
able, software development and maintenance costs should 
be reduced. In the API a special utility was used to create 
an object-oriented environment from C language programs. 
The box on page 29 describes some basic object-oriented 
concepts and an overview of the API object-oriented envi- 
ronment. The special utility used for creating the object- 
oriented environment is described later in this article. 

Input Handling 

The input handling model for the API is ba.sed on X, Xt 
intrinsics J and widgets. The Xt Intrinsics provide a way to 
call application functions when certain events occur. These 
functions are called callbacks and are attached to widgets. 
The Xt Intrinsics provide input handling capabilities for 
X events, time-outs, and file descriptor input through the 
XtMainLoop function. This function consists of an infinite 
loop calling XtNextEvent() to get the next event and XtDis- 
patchEventO to send the event to the appropriate processing 
function (see Fig. 3]. Because the API provides several spe- 
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cial input features the project team implemented its own 
version of XtMainLoop, 

The basic API input loop consists of an HP-UX seieetO 
caii to see if input exists on either the user's file descriptors 
or the API server ob|ect's file descriptors and a test to see 
what events came in (see Fig. 4). If input is pending on the 
file descriptor for the X ser\'er a message is sent to the API 
sender ohjecl to process all X events queued. If input is 
pending on a user's file descriptor the user's callback fiinc- 
tian !s invoked. 

The server object still does the XtNejrtEveniO and XIDis- 
patchEventO looping but it has additional code to handle 
conversion of X callback information to API format, 
callbacks on graphic objects and window objects. Expose 
and ConfigureNotify events on window objects, global 
callbacks, and event grabbing (see Fig. 5). 

Callback Handling 

CtillbacL*5 are implemented as objects in the API. These 
objects contain a painter to the user-written function to be 
called when an X event occurs, a pointer to callback-spe- 
cifir data, and the specific reason that will cause the 
callback to invoke the user function (see Fig. 6), The file 
descriptor that is checked during input processing is an 
example of callback-specific data. The reason for the invo- 
cation of the callback is an integer value that indicates the 
type of input event such as a button pre^s. These callback 
objects are put in a list called a callback list and are attached 
to the object requiring them. For I he Xt Intrinsics, the 
callbacks are attached to specific-reason resources instead 
of one central callback list. The API method of handling 
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callbacks eliminates having one attribute per callback for 
each object type and eliminates having to add and delete 
attributes when reasons change. Time-outs and file de- 
scriptor callbacks are attached to the API system object, 
w^hich stores global attributes and resources. X event 
callbacks are registered on the window objects. 

The API creates an identifier (Ztid) for each object that 
an application creates. However, the data returned to 
callbacks from a widget consists of a widget identifier and 
widget-specific data, which is unusable to API applica- 
tions. This problem is solved by minifunctions that are 
registered with the widgets. These minifunctions are inter- 
faces that convert widget -specif ic data into something that 
can be understood and used by the API. When a minifunc- 
tion is attached to a widget, the object identifier Ztid is also 
attached to the widget. This scheme allows widgets to be 
treated like other API objects when widget input is re- 
ceived. 
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Fig. 4, The API mpuf loop. 



Fig. 5, The API server object event handlmg /oop, 
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Callbacks on Graphics 

Graphic objects include shapes such as arcs, rectangles, 
and circles. Because graphic objects can be manipulated 
the same as windows and wudgets in the flP IVl environ- 
ment, we decided to have button press and button release 
events associated wuth them. Therefore, graphic objects 
need callback functions. For example, an octagon-shaped 
graphic object representing a stop sign may require a 
calll>ack object with a method for stopping some operation. 
Callbacks on graphic objects are handled differently from 
widgets. Since the graphic objects are not widgets, the Xt 
Intrinsics cannot be relied on to call API functions wben 
an event occurs on a graphic object. All widget and graphic 
obiects have a corresponding extent object. The extent ob- 
ject consists of tv\ro point ob|ects that define a rectangular 
region. When associated with an object* the extent defines 
the smallest rectangle that encloses an object (see Fig. 7), 
When I he m in [function for \vindow^ events detects a button 
press or button release, it converts the x,y coordinate posi- 
tion of the sprite to a point object Since the window 
mini function is called, this indicates that the button event 
did not occur over a widget [remember the widget mini- 
function converts widget data to API usable dataj. The 
button event results in a call to a function to find the object 
that is under the point. The function will search the hierar- 
chy for an object that has the point in its extent. If a graphic 
object is found, the object list is searched to see if there is 
a corresponding callback function and if so, the event is 
dispatched to the function. 

Global Callbacks 

A requireuieut of the API was to detect a function key 
press regardless of the location of the sprite in the wmdow. 
This was a problem if the sprite was over a widget when 
a function key was pressed because widgets grab any input 
over them. The project team extended the callback process 
so that the window object could also receive the event even 
if it was over a widget. This type of callback is referred to 
as a global callback. 

Global callbacks are implemented by providing an addi- 
tional check during the input processing in the server object 
(see Fig. 5). After the event is dispatched to the appropriate 
object, a check is made to see if global callbacks are enabled, 
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if SO, the event is dispatched again to ihe window object 
and any global callbacks attached to the window that match 
the event are called. For events that were originally over 
widgets, the x^y coordinates of the event are recalculated 
to be rektive to the API window object before dispatching. 
Recalculation of widget points is done because the API 
understands points relative to the window object coordi- 
nate system and not to the widget coordinate system. 

Event Grabbing 

For customers making their ow^n user-interface builders 
and also for HP IVIBuild^ a feature was needed lo direct 
events only to the window. For example, the normal be- 
havior for a widget pushbutton object is to flash when it 
is selected- However, in the builder, selecting the push- 
button may be the start of a move operation on it- To sup- 
press normal widget behavior and let the application deter- 
mine the meaning of the event, a button press event over 
a widget has to be directed only to the window^ object. The 
event has to be grabbed. To solve this problem, input han- 
dling at the server object level was modified so that if event 
grabbing is enabled, the event is only sent to the window 
object for processing. 

Window Expose and Resize 

When Expose and ConfigureNotify events occur on API win- 
dow or graphics objects, special functions are called in the 
server object to handle these events. Since graphic objects 
are not in individual X windows as the widgets are (see 
Fig. 8), the window object has to redraw the graphic objects 
w^hen an Expose event occurs and resize its children when 
a ConfigureNotify event occurs- 

For an Expos© event, the w^indow object removes all Expose 
events for tliis w^lndow from the queue and keeps two lists 
of corresponding extent ob|ects. Remember that an extent 
object consists of two point objects that define a rectangular 
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Fig. S. A cailback object in the API. 



Fig. 7. An API graphic object with an extent for defining the 
smaitest rectangle around a graphic object, (a) The graphic 
object (a arete) in a window and the extent represented by 
Pj and p2. (b) internal representation of the graphic object. 
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region. One list contains the extents of each Expose event 
in device coordixiates. This list is used in the ser\^er object 
to create X clip rectangles when graphics objects in the 
exposed region are redrawn. The second List contains ex- 
tents of each expose event in normalized device coordi- 
nates. After constructing these two lists, the window object 
goes through a redraw pass of the objects in the window. 
When the graphics objects are told to display themselves, 
they check the previous normalized device coordinate clip 
hst to see if they are in the exposed areas. If they are, they 
send a message to the ser\^er object to do the X dravmig 
commands. This scheme ensures that only those objects 
that are actually exposed get redrawn by the server object 
and it significantly improves performance ii exposed ob- 
jects are only a small portion of the windov*;. 

For ConfigureNotify events, the window object sets the new 
window placement and size values. Then during the next 
redraw of the window; the objects are redrawn to fit within 
the new window si2e. 

Coordinate Systems 

The coordinate system concepts and techniques found 
in various graphics packages are incorporated into the API 
functions for drawing graphics objects, windows, and 
widgets on the display. The user can define the viewing 
area in w^orld coordinates (e.g., inches, feet, etc.) and the 
API functions transform these coordmates to a window in 
the X coordinate sy.stem pixels. 

A viewport is a rectangular portion of the display onto 
which window objects defined in world coordinates are 
mapped. Viewports are typically defined in a device inde- 
pendent coordinate system called normalized device coor- 
dinates, or NFDCs. In X a viewport is represented by an X 
window, which is defined in device coordinates (DCs)- The 
API allows users to define the position and size of a window 
object (viewport) with NDC coordinates. This allows a win- 
dow to be defined as occupying a certain portion of the 
totaJ display area independent of display resolution. Map- 
ping a window object described in NDCs to the device 
coordinates of a display is straightforward. When an appli- 
cation initiates drawing to a specific X server, the display 
resolution of the server is queried. The NDC values describ- 
ing the viewport are multiplied by this display resolution 



to get pixel values. Since NDCs use the lower-left corner 
of the display as the origin and X uses the upper-ieft corner 
as the origin, the y values of the viewport must be sub- 
tracted from the height of the display for compatibility 
with the X coordinate system. Since this calculation is 
done at run time, the application does not need to know 
the type of display the application is using. 

Consider a window^ that occupies the NDC region from 
fO.0.0.0) to (0.5,0.5) on a display that is 1024 pixels wide 
and 768 pixels high (see Fig. 9a)- When converted to DCs 
as explained above, the window occupies the region of the 
display at pixel locations (0.767) to (5 1 1 ,3S4) [see Fig 9b). 

The transformation equations for converting from NDCs 
to DCs are: 

PxDc = P%Nix: ^ [width of display in DCs/1 NDC) (11 

PvDc = PyNDC; >< (^^ight of display in DCs/1 NDC]. (2) 

To take into consideration the upper-left origin of the X 
Window System: 



P'vix; — height of display in DCs - PyDt:' 



(3) 



Substituting the values from Fig. 9a into equations 1 and 
3 and compensating for the starting pixel yields: 
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Fig- 9. (a) Window defined in normalised device coordinates 
(NDCs). (b) The same window defined m device coordinates 
(DCs) in the X Window System. 
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PixDC == 0.0 X 1024/1 = 
PiyDC = ^68 - (0.5 X 768/1) = 384 
PaxDC ^ (0-5 ^ 1024/1] - 1 = 511 
PayDC = 768 - [0.0 x 768/1) -1 = 767. 

These coordinate values are shown in Fig. 9b. 

To define what is drawn within the window object, the 
user defines what portion of ihe world coordinate (WC) 



space is viewahh^ in that area. This viewable area can he 
changed at run time to perform operations such as panning 
or zooming, To draw to the X window representing the 
user's window object, the API must convert all values in 
WCs into the device coordinates of the display. WCs are 
transformed to pixels in a two-step process. The first step 
Iransforms the WCs to NDCs and the second step transforms 
the NDCs to DCs. 
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Ever\' window object contains a viewport-to-window 
transformation matrix (VTM). This malrijc describes how 
to scale and translate the viewable WC region to fit within 
the windows A scale factor (SPl is calculated to scale tiie 
WC width and height to the width and height of the view- 
port. This scale factor for the x coordinate is: 

SY^ = width of the \\'indow in N'DCs-^ width of the 
viewable WC region in WCs 

and for the y coordinate is 

SFy = height of the window in NDCs^ height of the 
viewable WC region in WCs. 

For example, in Fig. 10a the vie\vahle area of the world 
coordinate window is defined to occupy a viewport in the 
upper-right quadrant of a display. The scale factors for 
mapping the WC region to NDCs in this example are: 

SF^ = [1 - D,5)/[110 - 10) = 0.005 NDCsAATC 

and for the y coordinate 

SF,. - (1 - 0.5)/(B5 - 10) - 0.0067 NDCsAVC 



For the pushbutton example the translation factors are: 
T« = - 0.005 X 10 = - 0,05 NDCs 



T. = 



0.0067 X 10 



0.067 NDCs. 



Adding the translation factor to the NDC points Fj and P^ 
results in: 



0.05 
0.3 - 



- 0.05 
0,05 = 



= ONDCs 
^0:25 NTX:s 



P^y = 0.067 - 0.067 = NDCs 
Pr^y = 0.318 - 0.067 - 0,25 NDCs. 

Fig. 10c show^s the results of the translation. 

Like most graphics packages, the API follows the conven- 
tion of defining the origin in the lower-left corner of the 
drawing area. However, because the X Window^ System 
defines the origin to be the upper-left corner, an additional 
translation factor (or flip factor) must be added in the y 
direction to move the origin from the lower-left to the 
upper-left corner. 

The NDC height for the window in which the pushbutton 
in Fig. 10 resides is 0.5 NDCs, CompensatLug for the flip 
factor (F) results in: 



To transform the pushbutton coordinates shown in Fig, 
IGa from WCs to NDCs: 

P,^ = 10 X SFx = 0.05 NDCs 
Pn^ ^ 60 X SF^ = 0.3 NDCs 



■ 2x 
Plv 



10 X SFy = 0.067 NDCs 
47.5 X SFy = 0,318 NDCs. 



Fig. t Ob shows the pushbutton scaled to NDC coordinates. 

The NDC system maps the coordinate (0.0.0.0) to the 
lower-left corner of a window. Therefore, if the viewable 
WC region does not map the coordinate (0.0,0.0) to the 
lower-left corner of the window, a translation factor is 
added to the NDC coordinates. The translation factors are 
computed as: 



P\y = F - P., 
P'^y = F - P,, 


= 0.5 - 
= 0.5 - 


- 0,25 = 0.25 NDCs 

- 0.0 = 0.5 NDCs 


P'lx = 0.0 
P',, = 0.25. 







and 



Fig. lOd shows the result of applying the flip factor. 

The scale factors, the translation factors, and the flip 
factor are incorporated into the viewport-lo-window trans- 
formation matrix VTM. Combining all the transformation 
factors in one matrix and performing the transformation 
operations looks like: 



T^ - - SF^ X [WC,, origin} 
Ty = - SF, X (WCy origin) 
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Fig. lOe shows the final transformation of the pushbutton 
NDCs to X window device coordinates. The coordinate 
points sliown in Fig. lOe are derived by substituting the 
values from Fig, lOd into transformation equations 1 and 
2 and compensating for the starting pixeL 

PixDC = 00 ^ 1024/1 = 
Piyoc ^ 0-25 X 768/1 ^ 192 
P^>.DC = (0'25 X 1024/1] -1 = 255 
PzyDC = (0 5 X 768/1] - 1 = 383, 

ModeMng Coordinates 

The API provides modeling transformations that allow 
any object within the user interface hierarchy to be trans- 
formed by scaling (enlarging or shrinking), rotation, and 
translation. This lets the user draw a symbol that can be 
reused by providing only the data that differentiates its 
position and size from another instance of the symbol. The 
API concatenates modeling transformations so that an ob- 
ject is affected by the transformations on its ancestors. This 
allows an entire subhierarchy of objects to be transformed 
by one operation on a common ancestor instead of requiring 
transformations on every object in the subhierarchy. These 
transformations are used when an object is being drawn. 
The modeling transformation values are converted to WCs 
by multiplying the transformation on an object to its WC 
attributes. A current transformation matrix fCTM] is main- 
tained during a drawing pass on the objects. Each object 
multiplies its transformation matrix with the CTM contain- 
ing the transformations of its ancestors. In the API. the 
CTM is initialized to be the VTM. Doing this reduces the 
number of matrix multiplications and improves the perfor- 
mance of the drawing operation. 

Adjustments and Scaling 

Besides allowing tlie application developer to work in a 
display resolution independent manner when creating the 
windows for an application, the world coordinate system 
allows a user to resize the window interactively and the 
objects to be redrawn without the intervention of the appli- 
cation. Changing the si^e of the window changes the NDC 
definition of the window. This change causes the seal in j^ 
factors in the VTM to be recalculated at the next display 
pass. The objects are either enlarged or .■shrunk to fit within 
the new w^indow size. When resizing a window, the user 
may change its aspect ratio. That is, the physical width-to- 
height ratio of the object may be different from the WC 
width -to -heigh I ratio. When this happens, objects begin to 
look distorted. For instance, a circle begins to look like an 
oval. This may be an appropriate action for some appUca- 
tions> but for others, especially those where the objects on 
the display are meant to represent something in the phys- 
ical world, the application developer wants the objects to 
maintain their width-to-height ratio. In graphics packages, 
these two modes of operation are referred to as anisotropic 
and isotropic scaling, respectively. The API window object 
provides the attribute ZtAOJUST which the application can 



set to ensure that the aspect ratio is maintained. If this 
attribute is set and the window is resized, the WC height 
or width mapping to the window is adjusted to maintain 
the original aspect ratio- This process results in modifying 
the scale factors stored in the VTM. This also results in 
more viewable WC space in the window in either the x or 
tbe y direction. 

Applying the various coordinate systems to windows 
and widgets has worked successfully. Specifying their po- 
sition and size in NDC or WC units allows the user to 
define them in the same manner as graphic objects. It also 
allows the application to be independent of the display 
and window size even as the user interactively resizes the 
window. 

Scaling and moving widgets works the same as for 
graphics objects. However, as tbe widgets scale smaller and 
larger, the font that they use does not scale because it is a 
bit-mapped font. The widget scales larger and leaves more 
space between the edge of the text and the edge of the 
widget or it scales smaller and closes in on the text, even* 
tually clipping it [see Fig. 11]- A few possible solutions to 
this problem exist. One solution is for the X Window Sys- 
tem to support scalable fonts. This will allow the font to 
scale with the widget. Another solution is to switch be- 
tween a set of fonts with different sizes as the object grows 
and shrinks. Widgets also cannot rotate from a horizontal 
base. In the API. when a widget Is rotated, its defining 
point is rotated^ and the widget is redrawn in the new 
position with a horizontal base. This allows the widgets 
to be rotated as part of a symbol and to move along with 
any associated graphic objects. Despite these differences 

(Connnued on page 30) 
Types of Files: 

Ctass Header File (e.g., circLe.h) 
Ctass Definition File (e.g.. drclec) 
Library Def Edition FiEe (e.g., graphic. r) 
Run-Time Class Information File (e^g^H circlcrtc) 
Glue File (e-g . class libsc) 



1, Run rtc on Library Definition File 



graphic. T 



.^ 



~^ ctiTGte.rN? 



-^ gr»phtc.li 



-^ graph Ic.c 



2. Compile thie Class Definition File 



clrcle^h 



^ 



-► circk.o 



3. Compile C Source File gfaphic.c Generated from nc Tool 



graphlc-h 
graphicc 



-^ graphic. t» 



4. Glue Library Defiriition Object File 



graphic, h 



-^ ^aaslibs^p 



Fig . 1 3 . Tne process of adding a new object to the API object 

hierarchy. 
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Object-Oriented Design in HP IVI 



HP IVI fs an object-onented system It uses a set ol facilrttes 
called the HP IVJ object-oriented environment (OOE) !o provide 
the framework for ds implementation The OOE has two parts: a 
messaging interface and a tool for compiling an external descnp- 
tion of Ihe class hfefarchy into C language code The C code 
defines the dispatch tables used by the OQE's interf ace tunct Jons 
to perform messaging (object communicatton) Presented here 
are some basic concepts of object-oriented design and an over- 
view of how the OOE implements some of these concepts 

Object-oriented design and programming are proving io be a 
natural and productive paradigm for software development be- 
cause they enable developers to represent relationships among 
system components and the lasks to be performed on these 
components in a more natural manner The marn concepts of 
this methodology include objects, messaging, polymorphfsm, 
and inheritance 

Objects. An object is the basic unit in object-oriented methodol- 
ogy, It is a structure that contains local data structures and refer- 
ences to local procedures (called methocis) that operate on the 
data {see Rg 1) The current values of an object's internal data 
define the object's current state. The object's behavior is depen- 
dent on its current state. The data inside an object is pnvate and 
accessible only through one of the methods associated with the 
Object- An object acts on its data when it receives a request 
asking one of its methods to perform some operation. This mech- 
anism is called messaging. 

Objects are created from a template called a c/ass. There can 
be many objects of each class. These objects are called in- 
stances of the class, Each instance is an independent object 
with its own data and state. However, an object instance has the 
same data structures, shares the same methods, and behaves 
the same way as all other instances of the same class. This 
means that objects of the same class will respond to the same 
messages — differences in object behavior depend on the current 
state (the values of the object instance's data). For example all 
object instances of an object class that draws rectangles will 
respond in the same way to a request to draw a rectangle. How- 
ever, because of differences in the state of the internal data 
structures, the rectangles may be drawn In different sizes, colors, 
and positions. 

The OOE tool mentioned above is called the rtc (run-time class 
Information) tool. The nc tool compiles a symbolic external rep- 
resentation of the class hierarchy into the data necessary for 



Object 





.Data Private^''^ 
* (o Object 



defining classes and methods for inose classes Tbe symbolic 
representation of the class hierarchy is compiled by Ihe rtc tooi 
to produce static tables called dispatch tabies which consist of 
two pieces: a category table and method tables. These tables 
contain information necessary to dispatch messages to objects. 
A unique key called the message selector is used to search the 
dispatch tables for a pointer to a function that will service a 
request. The rtc tool also generates a file containing definitions 
of symbolic names for the constants that represent the message 
selectors. Coding using the symbolic names tof the message 
selectors provides independence from the stnjcture of the under- 
lying dispatch tables and provides more readable code The m 
tool and the type of files it compiles and generates are described 
jn more detatl on page 31 . 

Messaging. Objects communicate with each other through mes- 
saging. Sending a message to an object requests that object to 
perform some action— usually the manipulatton of its internal 
data. Messages consist of a minimum of two arguments the 
receiver of the message (i,e., the object) and the message selec- 
tor. The message selector consists of a category name and a 
method name. The object receiving the message looks up the 
category selector in the category table and then looks up the 
method in the corresponding method table. This selection mech- 
anism is controlled by a set of centra! messaging routines. These 
routines are contained in the message interface to the OOE, 
Every object contributes a dispatch table that the messaging 
routines search to determine which object implements a function 
for a particular selector, Associated wrth each selector is a pointer 
to a m el hod that is called to implement the response to the 
message (see Fig. 2). 

This connection of a message selector to the appropriate 
method is called bmding. Binding can take place at compile time 
(early or static binding), or at run time (late or dynamic binding). 
The OOE currently implements static binding 

In the OOE, the message selector is the key to determining 
which function gets called when a message is sent to a particular 
object. The message selector is a 32-bit quantity consisting of 




Fig. 1. An object. The internal data stmcture is pnvate to the 
object and the methods have safe access to U^e data. 



message (QblflCLe, selector} 

t 

Fig, 2. Connectmg a message to a method in an object 
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message ||Objecl_a, Oisplay_TFme) 
ObJ&t:t_a 




|— m9»$a§e {OtJject_b. OispFay_Time) 

Ob]BCt_li 




> 1S:00:25 



Fig. 3. Polymorphism allows the same message to be sent to different objects regardless of 
their interne! data types and methods. 



two 1 6-bit fields The upper 1 6 bits of the selector defines the 

oltset of the category to which that message belongs in the 
class's category table. The lower 1 6 bits defrnes Ihe offset of the 
method function pointer jn the method table, 

If the vaJue of a particular position in the dispatch table is 
NULL, the messaging routines traverse up the class hierarchy 
searching for a method function pointer. When a function pointer 
is found, ft is copied to the position in the dispatch tables where 
the upward traversal of the class hierarchy began. This tends lo 
improve the performance of the messaging system over time 
because the amount of upward searching is slowly replaced by 
direct function calls and the null values in the dispatch tables 
gradually disappear. Also, the implementation of categories im- 
proves memory use by eliminating method tabfes when a class 
does not support that category. 

Polymorphism. The concept of polymorphism in object-oriented 
programming enables different types of objects to share a com^ 
mon operational interface and to be manipulated by user code 
independent of the actual types of objects, This means that the 
application program does not have to differentiate the object 
type at run time. This differentiation is performed automatically 
by the messaging system. Far example, a message to a clock 
object to display the time would redraw the hands in a particular 
position if the clock were drawn as an analog clock, while the 
same message would cause the time to be displayed in text 
formal for a clock drawn as a digital clock (see Fig, 3). The clock 
object is polymorphic because the same message can be sent 
to different objects. The application does not have to worry about 
how the time is drawn. That is determined when the method to 
draw the clock interprets the instance data that defines each 
clock object's internal state. A goal of object-oriented design is 



Root Class 




Fig. 4. Inheritance allows methods to be reused. 



to maximize code generality, flexibility- and reusability by defining 
common interfaces that can be supported by many different 
kinds of objects. 

The mechanism of searching the class hierarchy described 
above is how the OOE implements the concept of polymorphism. 
Inberitance. Inheritance provides the ability to create incremen- 
tal definitions of objects (i.e., one kind of ob|ecL can be defined 
incremenially in terms of previously defined objects). The new 
definition extends the existing deiinitions by adding data to the 
object representation, by adding new methods, and by extending 
the definition of existing methods. Using the update time example 
from above, the analog clock object that produces the graphic 
representation of the time might only implement the method that 
draws the representation of the clock and inherit the more basic 
functions (e,g., audible alarms) from the more general digital 
clock class. Inheritance allows object definitions to be shared 
(rather than copied) and customized by extension (rather than 
by modification), A goal of object-oriented design is to organize 
object definitions so that common behavior Is specified in shared 
definitions and object definitions can be extended. 

The external representation of the class hierarchy that is pro- 
cessed by the OOE class compiler (rtc tool) builds tables of 
function pointers. Entries that are not NULL in these tables Indicate 
that a particular class implements a particular method. NULL 
entnes indicate that a particular class inherits a particular method. 
The class compiler also declares a pointer to the class's parent 
in the hierarchy (see Fig. 4). The OOE messaging routines use 
this information to tfaverse upward in the class hierarchy when 
searching for a method. 

In object-oriented systems, classes may have one parent or 
many. Single inheritance allows a class to have only one parent, 
This is the model implemented by the OOE. Object-oriented lan- 
guages such as Smalltalk and C+-\- allow classes to have more 
than one parent. This is called multiple inheritance 
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between the operation of the widgets and the graphic and 
window objects p the coordinate system feature of the API 



still provides a large productivity gain for the application 
developer. 
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Obiect-Orienled Architecture 

Without using an object-oriented programming language, 
the API encompasses features provided by an object - 
oriented language through conventionaJ C langua^ fea- 
tures. The APrs architecture is divided into three layers: 
the API function layer, the API object layer, and the device 
dependent layer (see Fig. 12). The API function layer pro- 
vides the communication interface between a user applica- 
tion and the objects created by the application. It is a thin 
layer of code that validates the user's parameters and sends 
messages to the obiects to perform the tasks requested. The 
functions provided in this layer are described in the article 
on page 11 . In the API object layer, an object is created and 
destroyed and all manipulation of an object's data occurs. 
In the device dependent layer, ail the function calls to 
underlying subsystems are made to draw an object to the 
display. 

Messaging In the API 

The API consists of a nnm^ber of function calls that pro- 
vide the communication path between an application and 
the underlying objects manipulated by the application. 
Most of the API functions require objects as parameters- It 
is through this interface that an object's specific data and 
the functions I hat manipulate the data are accessed. In 
essence, the API hides from the user as much as possible 
the details of using objects. 

To provide the interface between an application and its 
objects, a preprocessor tool called rtc [run time class infor- 
mation) is used to define the API object messaging facility 
and class interitance hierarchy based on information from 
a group of description files. Every API class consists of a 
class header file and a class definition file. The class header 
file defines the data storage for each instance of an object 
of that class. This file identifies the object as a member of 
a class or classes and provides the connection to the set of 
methods that manipulate that object's internal data- The 
class definition file is a C program module that contains 
the methods tliat are specific to a particular class. The class 
header file must be included in the C program module so 
that the data structure of this object and the class definition 
pointer can be accessed, Once an object's data structure, 
class, and specific functions are defined, it needs to be 
positioned within the class hierarchy. The positioning of 
the class in the class hierarchy is determined by the nature 
of the class and the methods to be inherited. The simpler 
a class is, the higher up In the class hierarchy it is 
positioned. Conversely, a more complex class is positioned 
further down in the class hierarchy. The positioning of a 
class within the class hierarchy is defined within the library 
definition file. This file defines the methods that are avail- 
able for messaging to a class and the methods that can be 
Inherited by that class. 

Adding an API Object 

Adding a new class to the API class hierarchy is a four- 
step process. This process is illustrated for the circle class 
in Fig, 13. First, the library definition file (graplnic.r] is used 
as the input to the rtc tool. The rtc tool takes the library 
definition file and produces several files as output. One of 



these output files (drde.rtc in Fig. 13) is the run-time class 
information file, or .rtc file. A ,rtc file is created for every 
class defined in the library definition file. It contains the 
class definition structure and the method dispatch tables 
for that specific class. The .rtc file is included at the end 
of the class definition file for that class when the class 
definition file is compiled (step 2). In the third step the 
new librar>^ definition fdes (grapliic.h and graphic.c) are com- 
piled. Finally, the pointer to the new class must be added 
to the file that defines the class hierarchy. This file is called 
the glue file (dasslibs.c). In step four, dassHbs.c is compiled 
with the class header file [graphic.h) to produce the object 
file dasslibs.o.) When these object files (circle.©, graphiao, and 
dasslibs.o) are linked into an application, the addresses to 
the methods supported by the various classes are resolved. 

By using object-oriented technologies, the API is able to 
create graphic objects. Ooe problem users have with soft- 
ware systems such as the X library is that graphic primitives 
are not objects. The X librar>^ provides many graphic func- 
tions that operate on the individual pixels of a graphic 
display but the parameters describing the obfect are not 
kepC For example, if a circle is drav\Ti and the application 
simply wants to change its color from blue to red, all the 
parameters ( location v size^ line w^idth, etc.) to draw the 
circle must be passed to the X library function again. The 
API solves this problem by providing graphic objects using 
the rtc tool. This allows the user to describe the parameters 
of the object once and then make simple modifications 
only to the parameters that are changing. The application 
is freed from maintaining aU of the data necessary to redraw 
alJ of the graphical objects in the window. 

Conclusion 

The HP I VI project was successful in blending graphics, 
windowing. X toolkit ^ widget, and object-oriented tech- 
nologies in the internal design of the API, Because most 
of these technologies were developed separately, it was not 
always clear how to integrate them. The API solved mo.st 
of the problems encountered and as a result of this effort 
d high-level user interface toolkit was created that reduces 
the complexity of building a sophisticated graphical user 
interface for an application. 
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HP IVfBuild: Interactive User Interface 
Builder for HP IVI 

Using the fQcilities provided by HP IVt's application program 
interface, HP IVI Build allows developers to create and 
experiment with different types of application user 
interfaces, save them in files, and bind them to the 
functionality of the application at run time. 

by Steven P. Witten and Hal-Wen L, Bienz 



^^HE EDITOR/BUILDER COMPONENT of the HP In- 
I teractivc Visual Interface product is HP IVIBuild. As 
m its name implies, HP IVIBuild is a tool that is used 
to build user interfaces interactively. The ivindows and 
objects thai make up the user interface can be saved in a 
file and reused later by other applications using the API 
functions [see Fig. 1 ), HP IVIBuild is itself an HP IVI appli- 
cation program because it uses the API functions described 
on page 11 as a platform. Fig, 2 shows the architecture of 
HPlVlBuild. 

Early in the design of HP IVTBuild we realized that al- 
though the HPI\T application program interface [API] func- 
tions are several orders of magnitude easier to use than 
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Saved User/ 

Interfaces L 
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Restoring User ^ 
Interfaces and 
Addifig FunctiorraHty 



A|>pftca»on 
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Xlib, the X toolkit, and widgets, they are still very complex 
to many users. Therefore, an interactive user interface de- 
sign tool, HP IVIBuild. was developed to completnent the 
API functions. 

HP IVJBuild helps promote .software development pro- 
ductivity in areas such as rapid prototyping and the design 
and modification of user interlaces. For rapid prototyping, 
HP IVIBuild allows developers to create complex prototype 
user interlaces. The user can interactively place and size 
all of the primitive graphics and widget objects in a win- 
do w\ Once the objects are placed and sized, many of their 
physical attributes such as colors, shadows, strings ^ and 
fonts can be changed easily within HP IVIBuild- Even some- 
one who does not have any software background, such as 
a human factors expert, can use HP IVIBuild to design a 
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Rg. 1. HP fVtBuifd allows users to create and experiment 
With different user interfaces and save tf}em in files to be 
reused by other AP!appti€ations,(APi = application program 

interface of HP tVf) 



Fig. 2. The components that make up the HP tVIBuiid ar- 
chitecture. 
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complex user interface. This means thai an application's 
user interface can be prototyped and evaluated separately 
from the operations performed in the application. 

Besides restoring the user interfaces created with HP 
IVIBuild, the API functions in the application also make 
the objects in the interface react to user input. Callback 
functions, which are in\'oked in response to user input to 
the application, can be attached to those objects that should 
respond to user input. If the applicalion requires changes 
to the user interface in response to application or customer 
needs, the previously saved user interface can be modified 
with HP IVIBuild. If the changes involve adding new ob- 
jects, callbacks can be added to the new obiects using the 
API functions in the applicalion program. How^ever, if 
changes are made to existing objects, no changes need to 
be made to the application program. 

Fig. 3 shows the interface areas provided by HP IVIBuild. 
The functions of these areas are: 

■ Utility Box. This area displays current object informal ion 
and the meous for object manipulation, 

■ Tool Box, This is the area in which the user selects the 
objects to be manipulated. 

■ Workspace. This area displays the wtndow^s being 
created* 

Object-Oriented Design in IHF IVfBuild 

HP IVIBuild uses the .\P1 functions and the facilities 
provided by the HP IVI object-oriented environment to 
build its own object-oriented system. The object-orienled 



concepts of objects, polymorphism* and inheritance are 
incorporated into the design of HP IVIBuild. 
Objects. In HP rVTBuild objects are ver>^ simple data struc* 
tures called states. A state is the contexl of user input (i.e.. 
the operation in progress) at any particular point in time. 
All states are static (hound at compile time} and have the 
same structure. Only one field in the structure, called a 
message selector, is filled in at run time. This field is used 
to bind HP IlTBuild's user loterface presentation to its 
functionality. User interface binding and functionality^ are 
discussed later in this article. The following is the C lan- 
guage structin'e of o typical state object. 



CLASSVARS(CiassVarsJ 



extern struct ClassDef^DzRect; 



r Ttiis macfo is included for '/ 

r compatitiif ity with the HP I Vf "/ 

/• objecl -o rien ted en vi ro n nn e nt an d V 
r is not used by HP IVIBuild. 

/• Structure cental ni ng posters to ' 
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r tables. This stmcture is V 

r created by the AP I rtc tool . V 
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= N U LL /' g rou p memtaer s hi p i nf o rmati on. * ^ 
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Fig. 3* interface areas of HP 
IVIBuiid. 
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statEC char objectname[ ] = "s_rect' ; ,* this state s name '/ 



An state obfects have the foHowing structure- V 



static struct DzRact^ 

struct CJ ass D ef 'c I as s ; 
char*statename: 
fNT32dsindex: 
INTSautoterm; 



INT32 setector; 



rNT32*group; 



/" Pointer to the dfspatch tables. 

/* Pointe r to t h e St ate ' s nam e . 

r A unique id assigned tothrs state. 

/* Th is state ' s au tote rm i nat i on 

/* flag (WTRUE the state machine 

r terminates the state and if FALSE 

r an action by the user must 

/• terminate the state). 

/* Message sent to the current state 

r to cause a transition to this 

r state, 

/* Pointerto this state's group 

/* membership information , 



r Data values assigned to the fiefds defined above 



_state^rect = { 


/* fnitiafization. 




8i_DzRect, 


r Pointer to dispatch tables. 




object name, 


r Pointer to name. 




27, 


r State's id number. 




FALSE. 


/* State is NOT au tote rminating. 




_s_rect, 


r Message selector that causes 






r transition to this state. 




groupmembership 


r Pointerto group membership 




}; 


r infomriatron. 





i d State s_rect = (idState)^state_rect ; r A poi nte r to th is state • / 

/Mhat isused by HPIVIBuild */ 

r to access and man ipulate */ 
/* data I n thi s structu re . 

Inheritance, In iriP IVIBuild, as in most object-oriented 
systemSr state objects are arranged in a hjerarchy. At the 
root of the hierarchy is ei special state known as the root 
state (see Fig. 4). The root state in HP IVIBuild manages 
interstate transitions. Since the root state is at the tap of 
the object hierarchy , it implements many more methods 
than the other states in HP IVIBuild. Using inheritance, 
the lower-level objects inherit all the methods from the 
root state. This inheritance mechanism is used to imple- 




ment state transitions in HP IVIBuild. 
Polymorphism. HP IVIBuild's central niput handling facil- 
ity ^ which is called the stale mochinet depends on the 
concept of polymorphism. All states in HP IVIBuild have 
the same operational interface (i.e., the state object is 
polymorphic). Therefore to the stale machine, all states 
look the same and are able to respond to the same set of 
messages. The state machine does not know or care which 
state is currently active. It only knuws that the current state 
either implements or inherits all the methods that are the 
targets of messages being sent to ih 

The box on page 29 provides a brief review of object- 
oriented concepts and the HP IVI object-oriented environ- 
ment. 

Input Handling 

Messages sent by the stale machine to a particular state 
can result in either an interstate transition or an intrastate 
transition depending on the message that is sent. Interstate 
transitions are transitions among the various state objects 
of HP IVIBuildt and intrastate transitions are transitions 
within a particular state object. 

A new state becomes current by an interstate transition. 
Interstate ttcinsitions are handled by the state machine* All 
input in HP IVIBuild goes through the state machine. The 
state machine is an API callback function that is attached 
to all the components of HP fVIBuild's user interface and 
all of the workspace windows created by the user. The 
objects in the HP IVIBuild user interface are called user- 
interface objects, and the objects created by the user during 
Ein HP IVIBuild session are called user- workspace objects. 
Using this mechanism, HP IVIBuild is able to control the 
context of the user's input. This is an important require- 
ment of any interactive design tool. 

The state machine performs the following functions: 

■ It changes the active workspace w^indows w^hen the user 
requests it, 

■ It interprets the meanings [context) of the mouse buttons 
when they are pressed in the active workspace window 
according to a user-definable mouse button map. 

■ ft sends messages to the current state. 

■ It manages the state stack. The state stack is an array of 
message selectors for the state objects. 

■ It makes new states current and terminates others that 
have completed. 

The Current State 

There is always a state that is active. This state Is called 
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Fig. 4, A portion of the HP (VIButid object hterarchy. 



Fig. 5. The siaie stack 
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fhe current slate. The current state is always the state to 
which the state machine sends any messages. It is up to 
ihe current state to provide a target method for any mes- 
sages that the state machine may send it. The target method 
is located either by irDpiementation or by inheritance. If 
no operaUoQ is in progress {i.e., oniy one stale on the stack), 
the current state is the root state. If an operation ts in 
progress, the current state is the slate that implements that 
operation [e,g,» creation of an object such as a polyline or 
widget). 

No state knows which state was current before it became 
current and no state knows which state will become current 
after it ceases being current. These rules were strictly en- 
forced to ensure the black-box nature of each state's 
methods during design and testing. 

Once current* a state controls the context of the user's 
input according to a state transition mechanism of its own. 
These state transition mechanisms are called intrastate 
transitions and are controlled entirely by the state itself 
using a local variable called a substate. For example, mov- 
ing forward or backward in a sequence of actions that are 
part of one particular operation , such as creating a polyline^ 
is controlled entirely by the state itself. The substate mech- 
anism is described later in this article. 

State Stack Management 

During the execution of HP IVIBuild the states that are 
activated by the user are organized in a LIFO (last-in, first- 
out] stack (see Fig. 5). The state machine provides a mech- 
anism to suspend operations in progress to do another op- 
eration and then resume the suspended operation when 
the new operation finishes. The state at the top of the stack 
represents the current context of the user's input and is 
the current state. Only the current state can receive any 
messages. The maximum depth of the state stack is defined 
to be ten states. This is an adequate depth because there 
are other mechanisms in HP IVIBuild that prevent the state 
stack from growing to a depth of more than three or four 
states. The root stale enters the state stack first and remains 
there during the entire execution of HP IVIBuild. Therefore, 
the root state is always in the stack regardless of the depth 
of the stack. 

At each interstate transition, the state machine checks 
the autotermination flags of each state in the state stack. If 
the autotermination flag is TRUE, that state is terminated 
immediately by the state machine and removed from the 
state stack. The state stack is then compacted and the state 
ending up at the top of the stack is started. If the autotermi- 
nation flag is FALSE, only an action by the user can terminate 
the state. 

State Transition and Inheritance 

As iiientioned earlier, an interstate transition Is Ihe pro- 
cess of making a new state (a state not currently on the 
state stack) the current state. The new state is placed at the 
top of the state stack and started by the state machine. The 
stale transition process begins when an event occurs such 
as a button release over an object on the display. The first 
thing to happen is that the state machine function is called 
as part of the normal API callback processing (see page 23]. 
The state machine function is passed a pointer to the 



ZIUSEFLDATA attribute of the object that received the event, 
which has a pointer to the message selector that, when sent 
to the current state, will cause an interstate transition to a 
new state. The state machine sends the message to the 
current state. This process works the same way for HP 
ATBuild user-interface objects and user-workspace objects, 
except that user- workspace objects alwa\'s send a hrt mes- 
sage to the current state. A window created by the user is 
the only user- workspace object that functions like a user-in- 
terface object. A hit message results when a user presses a 
mouse button in a workspace window. 

If the current state can handle the message* the method 
that is called will either return a pointer to the current 
state or a NULL. This pointer is returned to the state machine 
as part of the normal message sending mechanism of the 
HP I\T object-oriented environment. States return pointers 
to themselves when they want to remain current. This will 
cause an intrastate transition. States return NULL when they 
receive an exit message and want to cease being the current 
state. This will cause an interstate transition. Fig. 6 shows 
a portion of the state transition process. 

Since the root state is the parent of all other states, the 
interstate transition process depends heavily on inheri- 
tance. Each state inherits all the methods from the root 
state. When a state receives a message for which it does 
not have a method , the HP IVI object-oriented environment 
will search the current state's lineage (object hierarchy) 
until it finds the target method for the message. In the case 
of an interstate transition, the target method will always 
be found in the root state. The target method in the root 
state returns a pointer via the object-oriented environ- 
ment's messaging system to the state object thtit is to be 
made the current state. This is the pointer thai the state 
machine compares to the value of the pointer for the current 
state. When it sees that the two pointers are different, it 
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placKfs the new pointer at thd top of the state stack (making 
the state current) and sends a start message to the new state. 
Thos, by inheritance, every state object has the ability to 
activate any other state object* 

When aji intrastate transition occurs, there is no change 
to the current state (i.e.. the pointers are equal]. The current 
state handles the incoming message itself. 

State Protocol 

All states follow a specific protocol that is implemented 
m the state machine of HP IVJBuild. Fig. 7 illustrates this 
protocoL An inlerstate transition (Fig. 7a] occurs w^hen the 
current state receives an exit message and it returns a NULL 
to the state machine indicating that it %vants to cease being 
the current state. The state machine makes the new state 
the current state and sends a start message to the new state. 
The new state remains the current state as long as it con- 
tinues to return a pointer to itself to the state machine (e.g., 
Current^Staie in Fig. 7b). Following this protocol allows a 
state to control the meaning of user input within its own 
context. Each state implements or inherits five standard 
methods that constitute its operational interface: start, hit, 
backup, undo, and exit. 

Start. As shown in Fig. 7, the start message is the first message 
a state receives before any other message is sent to the state 
(except exit]. 

Hit. A state gets a hit message when the user presses a mouse 
button in the workspace window that is currently active. 
HP IVIBuild allows the user to construct and edit as many 
windows as desired but only one can he active at a time. 
To activate another window, the user only has to press a 
mouse button over the window that is to become active. 
Depending on their htit methods, states are classified as 
either multiaction or single-action states. 

A multiaction state requires the user to select multiple 
points in the active window to perform the operation im- 
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plemented by the state. An example of a multiaction state 
is one that allows the user to create polylines or splines. 
When the user presses a mouse button in the active wmdow 
and a multiaction state is the current state, the action of 
the state is said to go forward. Fig. 8 shows the intrastate 
transition diagram for a multiaction state that translates 
objects. 

A single-action state does not re<iuire a hit in the active 
window to go forward. Single-action states caji only do 
one thing. An example of this are selections (he*, states 
that select certain kinds of objects for further operations). 
Once the class of objects that are to be selected is known, 
the objects are selected and no further input from the user 
is required. Any single-action state that receives a hit mes- 
sage is terminated and removed from the state stack. The 
hit message is sent to the the new current state. Fig. 9 
sho^vs tlie intrastate transition diagrajn for all single-action 
states. 

Backup. All multiaction states implement backup. This is 
the reverse operation of a hit message because it allows the 
user to cause the action of the state to go backward over a 
previously sent hit. No single-action states unp lenient back- 
up. 

Undo. All .states implement ur\6o. Undo allows the user to 
back a state up to the point right after it received its first 
start. This has the effect of undoing any actions that had 
been performed by the state. Undo may also be sent im- 
mediately after a previous undo to effect a redo operation. 
Exit, A state is sent an exit immediately before its removal 
from the state stack. This allows the state to reinitialize 
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itself for its next activation. 

The Substate 

Once current, a state controls its own actions using a 
local variable called the snbstate. During a sequence of 
operations, the messages siart, backup, hit, and yrxto may be 
sen I repeatedly to the current state. These actions do not 
cause interstate transitions. Rather, they cause intrastate 
transitions. The current state does not change but the mean- 
ing of the next input event may have to be interpreted 
differently depending on the sequence of messages the state 
has received since it was made current. The value of the 
substate is changed to reflect the context of the next hit* 
backup, or undo. Note that start is always sent after every 
action whether the action causes an intrastate or interstate 
transition. This is part of the protocol established for a 
state by the state machine, 

Untformjty 

Great care was taken to ensure that the same actions have 
uniform behavior no matter which state is current- The HP 
IVIBuild team developed guidelines for developing states^ 
and intrastate transition diagrams were developed before 
the development of a particular state so that the unifonnily 
of actions could be assessed by the whole team. The result 
is a tool with ver^' modular units of functionality that all 
behave in a consistent and intuitive manner. 

The HP rVIBuild User Interface 

HP IVIBuild 's user interface was designed as a collBbora- 
tive effort between the HP IVIBuild team members and the 
industrial design department at HP Software Engineering 
Systems Division (see the article on pag^ 39), The objective 
of the collabonUiun was to design a user interface for HP 
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IVIBuild that was both attractive and intuitive to the user. 

Besides the appearance, HP IVIBuild is structure<i to han- 
dle native language support and user customization. One 
other interesting feature is that the HP rVIBuiid user inter- 
face presentation is not bound to the finictionalit>^ until 
run time. 

Native Language Support and Custom i^atton 

HP IVIBuiid's user interface conforms to HP standards 
regarding support for native languages and cultures. All 
text that is presented to the user such as labels, prompts, 
and error messages is contained in message catalogs and 
is retrieved by HP fVlBuUd at run time. To localize HP 
IVIBuild, the user only needs to change the contents of the 
catalogs. In generaK these tasks are performed by HP per- 
sonnel in I he country whose native language is the target 
language. This way, text can be presented with as much 
context sensitivity as possible. Idiomatic nuances of text 
presentation are not lost (as they sometimes are with 
straight translations). 

^\nother feature of HP WlBuIld's user interface presenta- 
tion is that colors, tiles, fonts, mouse button bindings and 
icons can be customized for individual users by modifying 
the X Window System configuration file .Xdefaufts. This 
mechanism alhnvs individual user.s to customize the pres- 
entation of IVlBuild's user interface lo suit their own needs 
[e.g., left-ban dedness. black-and-white display). 

Presentation and Functionality Binding 

The presentation of the components that make up the 
user interface of HP I\TBuild (i.e., the buttons, menus, win- 
dows, etc.) and the functionality (the states) associated with 
these components are bound together at run time. The func- 
tionality of HP IVIBuild. I hat is, the result of pressing a 
certain sequence of buttonSt ii> not dependent on the user 
interface presentation. F''ar example, in one user interface 
presentation, drawing a rectangle might be accomplished 
by selecting buttons labeled PI and P2 for the lower-left 
and upper-right corners of a rectangle and typing the coor- 
dinates into a pop-up dialog box. In another user interface, 
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drawing a rectangle might he a three-button sequence in 
which the user presses the Rectangle button and then clicks 
on the desired coordinates with the mouse. In either inter- 
face, ttie state operations result in a rectanglt^ 

The bintUng of functionaiity to user interface presenta- 
tion is done wtien HP iVlBuild starts up. At this time the 
objects (windows, menus, buttons, etc) that make up the 
HP IVlBuild user interface are restored from a file. Pointers 
to objecls (Ztlds) tliat activate states or send messages to the 
state machine are looked up using the name of [hn object 
that was assigned when tfie object was created with the 
API functions. This lookup is accomplished using an API 
function. When the Ztid for an object is returned, the mes- 
sage selector for the state to he activated is retrieved. At 
this point a callback object [ZtCALLBACK_OBJ), which will 
call the state machine whenever an event occurs on the 
user interface object, is created for the user interface object. 
Also, the message selector from the state objecl is made an 
attribute [ZtUSER_DATA] of die user interface object. Once 
the callback object is attached to the user interface object, 
the binding is complete (see Fig, 10]. When a specified 
event occurs on a particular user interface object, the in- 
terstate transitions described earlier occur. This scheme 
makes the state machine a callback for every IViBuijd user 
interface object and for every workspace window the user 
creates. 

Separating the user interface presentation from function- 
aiity means that the presentation can be developed inde- 
pendent of functionality and the same functionality can be 
easily given a new presentation. New functionality can be 
added and tested in a straightforward way without worry- 
ing about its presentation. 
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Conclusion 

IIP IVlBuild v^as conceived with two objectives in mind; 
to be a powerful, easy-to-use tool to complement the HP 
IVl application program interface functions and to be the 
first API application and as such to provide feedback to 
the API development team. Both of these objectives have 
been accomplished. We believe that HP IVIBuild's func- 
tionality and designed'in extensibility based on an object- 
oriented architecture are among the first for tools of this 
type. 
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Creating an Effective User Interface 
for HP IVIBuild 

The HP IVIBuild user interface was a cottaboratlve effort 
between the software engineers developing the code for 
the product and a group of industrial designers who 
understand the requirements of an effective graphical user 
interface. 

by Steven R. Anderson and Jennifer Chaffee 



AMONG THE PRESENT and potential customers for 
HP's computer systems are companies that are in- 
creasingly integrating computers into their manu- 
factuTing processes. However, the computer focus of these 
companies is more on solutions than on hardware and 
software development. To help provide these sohilions on 
HP computer systems there are efforts within the company 
to encourage or enable independent software vendors 
(ISVsj to develop these software solutions. HP IVI from 
HP's Industrial Applications Center (lAC) is one such effort. 
Its purpose is to help ISVs build graphical user interfaces 
for their applications used in industrial applications. 

Why the need for a graphical user interface? Many of the 
operators and users of computer-based systems in an indus- 
trial environment Eire not computer [iterate. They typically 
perform tasks like controlling an automated spray paint 
line, and the interfaces to the tools they use are typicaliy 
knobs, dials, bultoos and other physical and visual ob|ects. 
A command line interface is a totally foreign approach for 
these people^ and many of them refuse to deal with it, 
Whatever can he done to enable the uiterfaces to come 
closer to the users' current way of doing things is seen as 
having value, A graphical user interface is seen as having 
the greatest potential in making the interface familiar. Re- 
cent developments in user interface technologies^ are very 
suitable for graphical user interfaces in industrial automa- 
tion applications. 

Background 

HP IVIBuild is a tool that enables users to develop graphi- 
cal user interfaces interactively. Therefore, it seemed 
appropriate that it should have a graphical user interface. 
For tliis capabilily rhe HP IVIBuild developers decided to 
use the graphical user interface components that were 
under development at HP's Interface Technology Operation 
(ITO) in Corvallis. Oregon. These components are com- 
monly called widgets.^ They include things like menus, 
scrollbars, pushbuttons, text-edit boxes, and radio buttons. 
They are the raw materials from which a graphical user 
interface is assembled. The HP IVIBuild team had no idea 
thai using widgets would lead to collaborating with visual 
design professionals. 

Neither did we, the visual design professionals, know 
about the HP IVI team. We are the usability design and 



engineering group of HP's Software Engineering Systems 
Division (SKSD). We are former industrial designers who 
switched our design focus from designing hardware enclo- 
sures to the area of aser interfaces, plus one graphic design- 
er. At the time our division was developing what would 
became the HP SoftBench environmentf'* and we iverealso 
iooking to ITO for the necessary widgets. Rather than pas- 
sively waiting to see what they might provide, we were 
encouraged by our management to lend our professional 
expertise to the widget development, and ITO was open- 
minded enough to listen to some of our ideas. 

We didn't begin with any proven graphic user interface 
expertise. We had done some design analyses of the leading 
graphical user interfaces. Also, coming from a background 
in which our experience and training forces us to process 
informal ion visually gave us some ideas about how an ef- 
fective graphical interface should look. And because our 
experience with software and computers was limited to 
being application users, we had some first-hand kno^vledge 
jjbout the user interface requirements for users who are not 
software literate, 

Basic Principles 

Three principles have established the foundation for 
graphical user interfaces iti recent years, notably in office- 
oriented applications. The first principle is that it is easier 
for most people to have their alternatives presented to them 
in a manner that allows them to make choices rather than 
having to remember all of the alternatives. Choosing a com- 
mand from a menu is often easier than remembering it. 
The second fundamental principle is that making these 
choices by some means of direct manipulation is often 
preferred over typing in text commands. Pushing a button 
or dragging a file icon into a folder icon or a trash can are 
two examples of direct manipulation. Finally, the third 
principle is to use metaphors from the real world. For exam- 
ple, we know what to do with a pushbutton. 

In our analyses of the many graphical interfaces existing 
today, one of the impressions we formed was how confus- 
ing they could be because of the flat and bland graphics. 
This is especially true in mult) window environments in 
which there is a high degree of overlapping and the simi- 
larity of the graphic images seems to blend all the images 
together into one confusing mass. We thought that creating 
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greater visual distinctiveness between objects would signif- 
icantiy enhance a user*s ability to Jteep things sorted out. 

30 Appearance of Widgets 

Our first attempts to express widgets grapliically were 
with the traditional black lines on a white background. To 
get away from the sameness mentioned above, some of the 
widgets were drawn to look three-dimensional and to look 
and act like pushbuttons. It soon became apparent that the 
displays of the future would not be constrained to simple 
black and white^ and that larger areas of solid color could 
be used. This was a significant breakthrough- 

With the capability to use color, we added three colors 
to the black and white. By using light, middle, and dark 
versions of a color, we could make a button look very 
three-dimensional. This was achieved by making the top 
and left edges light, the flat surfaces the middle value, and 
the bottom and right edges dark. This technique makes it 
appear as though a light is shining on the button from the 
upper left. Another nice by-product of this technique is 
that by momentarily switching the light and dark colors 
when a button is selected, it actually appears to be pushed 
in. It was so effective that people got a little silly pushing 
buttons the first time they saw a working prototype. 

People intuitively grasp the notion that if something ap- 
pears to protrude, it can be pushed or selected to generate 
some action. Widgets that accept or display inputs appear 
to be recessed. Noninteractive things like labels are fiat. 



Scrollbars are hybrids, with a recessed groove containing 
raised controls. Menu bars look liJce large buttons with 
several labels on them. When the mouse drags over a menu 
item, it appears to raise, transforming itself into a button. 
When a menu item is selected by releasing the mouse but- 
ton, the feedback mechanism is the same shadow reversal 
the pushbutton uses to appear recessed. Fig, 1 .sthows the 
transition from a total 2D appearance to a full 3D appear- 
ance. 

Most people found this 3D appearance appealing. It be- 
came a key factor in the subsequent adoption of the HP 
widgets by the Open Software Foundation (OSFj for their 
OSF/Motif standard user interface.^ 

A New Principle 

The 3D appearance ends up creating a new fundamental 
graphical user interface principle: the visual separation 
and distinction of what we call user space and interface 
space. User space is where the user's inputs go. or where 
the user performs work. Examples are the space provided 
in a word processor for entering text, or the space provided 
in a paint program for creating images. It also includes 
those areas where the user is asked to input data like the 
name of a file. 

The rest of the screen is the interface space, or the visual 
manifestations of the applications and/or the operating sys- 
tem. Included in this category are items like window 
frames, dialog boxes, tool panels, menus, and themetaphor- 
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ical desktop. The interface space, whether controlled by 
the application or the operating system, is where all of the 
3D effect is found. 

In office-oriented applications, which have been driving 
the graphical user interface movement to date, the 2D user 
space is usually dominant in terms of screen area. The 
main focus of these applications is generally to provide a 
tool that allows the user to create different forms of docu- 
ments such as mail messages, memos, charts, spreadsheets, 
overhead slides, and newsletters. Based on these applica- 
tions, the user space is perceived to he the W^'SIWYG 
equivalent of some sort of paper document, whether a small 
notepad or a large drawing. It is predominantly two-dimen- 
sional, which is appropriate because the resulting docu- 
ments are also t^vo-dimensional. 

There is an emergence of graphical user interfaces in 
which the interface space dominates because the main 
function of the applications is not document creation hut 
some form of process setup and control. Examples include 
things like configuring and ruuning a set of test instru- 
ments , or monitoring and controlling a complex tempera- 
lure control system or an assembly line. HP I\lBuild is 
geared to create interfaces of this latter ty^pe. The 3D widgets 
(or OSF/Motif widgets) are particularly we 11- suited to this 
type of interface because the physical reality they convey 
is much closer to the mental model most people have of 
activities that are control-panel oriented. Fig. 2 shows one 
window for an office- oriented application and another for 
an instrument control panel. 

HP IVlBuild before Redesign 

In the early stages of development, the HP IVl team used 
the initial version of the widget code from HP's Information 
Technology Operation. The early results of their using this 
code produced the 3D appearance shown in Fig 3, Unfor- 
tunately the 3D effect was largely lost and the user interface 
was hard to imderstand. This early result was not a surprise 
because ihe HP IVlBuild team had not yet had enough 
experience with widgets and consequently had little notion 
of how to achieve and use the 3D effect- They were also 
unfamiliar with many of the standard techniques and prac- 
tices for creating graphical user interfaces. 

Our group had concurrently benn using the 3D widgets 
with our own HP SoftBench tools. That successful experi- 
ence plus the acceptance of HP widgets for OSF/Motif gave 
us a certain amount of credibility. As a result we soon 
found ourselves in contact with the HP IVlBuild team. Like 
our experiences with the ITO team in the development of 
widgets, the HP fVIBuild people were very open-minded 
in letting us get involved with their product. 

HP IVlBuild was different for us in that it not only uses 
conventional wndgets to create a graphical user interface, 
but it can also create graphic objects that behave like 
widgets. What this means is that buttons and scrollbars 
can be supplemented with graphic representations of ob- 
jects that can change to reflect current status. For example, 
a graphic image of a storage tank can change to show the 
current level of the liquid it contains, or an assembly line 
schematic can be changed to reflect the status of each work 
cell The output of HP IVlBuild con range from simple 
windows with menu bars and dialog boxes to very complex 



controt-panel-Uke layouts with animated graphics and 
numerous controls. These capabilities w^ere not obvious in 
the original interface shown in Fig. 3, 

The Stmctyre of HP IVlBuild 

The HP IVlBuild user interface is divided into three parts: 
a utility box, a tool box, and a workspace. 
The Utility Box. This area holds the menu bar, a prompt 
window, several status indicators, and some commonly 
used commands in the form of pushbuttons. 
The Tool Box. This area is Uke a paletle of various graphic 
ur widget creation tools. It has three modes: graplucs, 
widgets, and models. The graphics mode functions like a 
typical paint program, displaying numerous drawing tool 
buttons as well as mechanisms for displaying and selecting 
items such as colors, patterns, and line w^eigbts. The widget 
mode is used for creating and specifying the widgets. The 
models mode is used to get access to models, which are 
templates or libraries of previously created work. Fig. 4 
shows the utility box and tool boxes at an early point in 
the design stage of HP IVlBuild. 

The Workspace, This is the area in which the user does 
the work of building a user interface, in this area graphic 
or widget objects are put together on a kind of three-dimen- 
sional sheet of paper. After assembly, they are stored away 
for use as finished products or as models for reuse or mod- 
ification. For example, a simple dialog box might be used 
as a template for other dialog boxes, eliminating the need 
to start each one from scratch* 

Collaboratlort 

The early efforts by the industrial designers focused on 
sorting out the functionality found in each of the HP 
IVlBuild areas and then f ind ing reasonable ways of present- 
ing each area. The utility box and the tool box visual layouts 
received the most attention. One of the first steps was de- 
termining the menu structure in the utility box. Certain 
conventions and many examples exist in industry showing 
how applications organ i?:e and perform activities like edit- 
ing and filing— for example, the locations of commands 
like cut, copy, paste, and quit in a word-processing package. 
And certain conventions exist in terms of dialog box layout, 
like where the OK, cancel, and help buttons should go. We 
followed accepted general practices wherever possible, and 
tried to develop acceptably solutions whore no previous 
models existed. 

The tool box with its various modes was probably the 
most complex job. The final layout chosen for the tool box 
owes many of its approaches to showing status and offering 
choices or functions to existing de facto standards for paint 
programs. There were instances where we were forced by 
technical limitations to deviate from these standards. For 
example, a simple draw tool like the one used to draw a 
rectangle typically requires a decision about whether the 
rectangle is to be filled in or left as an outline. A typical 
solution is to have one button with a rectangle on it. with 
the left half hollow and the right half filled [what looks 
like one button is in fact two buttons), in our case the 
widgets wouldn't allow that approach, so we ended up 
with a separate button to turn the fill function on or off. 
Fig. 5 shows the design recommendation for the utility and 
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Frg. 2. One wv/r?dow w^fii a typfcai 
2D office -onentad application and 
the other window showing a 3D 
instrument control panel. 



tool boxes at a later stage in the development. 

GolorH were another area where the designers had some- 
thing Eo contribute. We had some color schemes in hand 
from our earlier worJc on widgets as well as from our work 
with HP's Soft Bench product. This greatly simpiified the 
tricky decisions required to convey the 3D quality of 
widgets. We provided the color names and RGB values that 
had to be assigned to each widget component to make the 
3D effect work and provide a pleasant overall interface. 



Fonts were also important. Graphical user interfaces in 
generals and the 3D widgets in particular^ are very much 
dependent on good fonts to be successful. While the popu- 
lar notion of a graphical interface centers on icons, most 
of the wT)rk is still done with words, and good pro- 
portionally spaced fonts make w^ords work better, The HP 
I VI Bui Id team decided to use some display fonts that had 
been created by HP expressly for 3D widgets. These fonts 
provided both behavioral benefits [text properly centered 




Fig, 3. A very early version of 
HP IVlBuifd when the design team 
first began to use wfdgefs. 
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in widgets, text baselines iined up, etc.) and a cunNistent, 
high-quality look. 

The designers also creEitetl all of the bit majis and icons 
associated with the tool boxes and other aspects of the 
product. One challenge with many of the tool box buttons, 
especially for those in the widgets mode, was to express 
the 3D nature on a small scale and with only two uolors- 
The illusion of using three colors was achieved by using 
a light and a dark color and then introducing a dithered 
pattern that the eye blends together to form a third color 
(see 1^'ig. fij. 

The final area of CQllaboration was to do something visual 
and graphical to help explain and sell HP IVlBuild- Some 
sample screens were created that express how HP l\TBuild 
can af:tually be used. With just a little prompting on how 



Fig. 4. The visual designers* first 
proposal for the HP iVIBuifd user 

interfsce. 



to use the 3D effect, a designer used HP IVlBuild to create 
two sample screens for each of seven potential application 
areas. These compelling images, achieved through the use 
of the actual tool have done more to explain HP t\TBuild 
and its capabilities than a volume of marketing brochures. 
One of these sample screens is shown in Fig, 2 on page 8. 

Concluston 

We learned a few things as a result of this collaborative 
exercise. One is that experts often have problems com- 
municating their concepts and ideas to nonexperts. In this 
ca.se we had two groups of experts. We found that it was 
important to have a main conduit or interpreter between 
the user interface designer and the rest of the software 
team. Without someone to answer all of the questions the 




Fig. 5, A later vers!On of the user 

ir}terface after tr}corf>Qrat!ng some 

of the impiementaUon limitations. 
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user interface designer asks, drid interpret the various 
dialogs with the team members, the communication pro- 
cess really breaks dowon One designer interfacing with a 
haif-dozen individual team members means a half-dozen 
different interfacing styles. 

Another lesson we learned is how important it can be 
to have an early vision of what you are trying to do. Tools 
exist that enable designers to create this vision and user 
scenarios quite quickly. The power and usefulness of these 
visuals should not be underestimated. They are pow^erful 
catalysts for people's thinking and communication. Once 
these are analyiced. discussed, and modified, the product 
is better understood by all concerned. Only at this point 
should the interface coding begin. The mistake should not 
be made of bringing the visual design help in at the very 
end to fix up the icons. Chances are the flaws go far beyond 
cosmetic graphics, and at this point the investment has 
been so great that sigaif leant changes are nearly impossible. 
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Born m Switzerland, he lives ^n Cupertino, Caltfor- 
ma. and enjoys mountain hiking, biking, andtjsten- 
mg to old lazz recordings, 
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Asad Aziz 

tNow a marketing account 
cTianager for HP's Circuit 
Technology Group. Asad 
AzjT^ was previously m RAD 
where he worked on the de- 
sign, layout, modeling, and 
electrical model verification 
of the PCX CPU package 
Before that, he worked on 
packaging RAD for HP PA- 
RISC computers, and on TAB design and etecmcai 
modeling Asad joined HP's Colorado Integrated 
Circuits Division m 1965. shortly after he graduated 
from Bngham Young University with a BSEE degree 
in 1 9B4, He received an MBA degree in 1 990 from 
the University of Denver A member of the lEEF, he 
has Goauthored two techmcai papers on packag- 
ing Born in Lahore, Pakistan. Asad iS married and 
lives in Fon Collins. Colorado, He enpys squash, 
bicycling, and windsurfing 



Ravi Kaw 

I Ravi Kaw developed a 
I rnpinodo^ogy to measure R, 
nnd C parameters m 
^S.i packages usmg coax- 
I lal probes rather than cus- 
tom-designed boards 
Since joining HP in 1 982, he 
has served as a product 
engineer for DRAM and 
I math chips and as a 
semiconductor process engineer, and has worked 
on package measurements and modeling re- 
search Before pining HP. Ravi was a lecturer at 
Kashmir University and an engineer at the Jet Pro- 
pulsion Laboratories and Fairchild Semiconductor 
Cofp He IS the author of 14 technical articles on 
device physics, device modeling, packages and 
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systems, and measuremenl methods His work has 

resulted in two pending patents on packaging 
structures and systems and measurefnent methods. 
Ravj is a member of the IEEE and the International 
Packaging Society. He received his BE degree in 
1966 in electronics and telecommuntcatjons trom 
Jabalpuf University, his MSEE degree In 197? in 
mrcrowaue sol td- state devices tfom Marquette Uni- 
versity, and his PhD degree in 137S in solid-state 
electronscs, quantum etectronjcs-, and microwaves 
trorn the University of California at Los Angeles. 
Ravi is a member of the t:jo3rd of directofE of a locaJ 
Hindu community and cufturat censer, and a Sun- 
day schoof teacher. Bom in Snnagar. Kashmir, 
India, he is married, Has two children, and resides 
in San Jose, California He enjoys jogging , garden- 
ing, hikeng, and readsng. 



David W. Quint 

Before Dave Quint [oined 
HP's Desktop Computer DJ' 
V'Sion in 1 979. ne helped 
design nuclear reactor 
conlrol systems for Westtng- 
house-BeUjs Atomic Power 
Laboratones As an HP 
R&D design engineer, he 
^^ . developed tape automated 

^M / J bonding (TAB)and pin-grid 
array (PGA) packaging for VLSI circujts. He is now 
an R&D engineer working on integrated circuit 
packagrng al HP's Colorado Integrated Circuits Di- 
vfsion Dave's work has resulted m two patents, one 
describing a method of sampling a 1 00-GHz opti- 
cal pulse stream, and another for a method of de- 
positing tungsten for integrated circuit intercon- 
nects. His professional interests include integrated 
circuit process engineehng, electromagnetic 
fields, circuit analysis, and optical electronics. He 
published a paper in the Journal of Applied Physics 
whife at MIT, and has coauthored three conference 
papers on electronic packaging. He received hrs 
BSEE degree in 1972 and MSEE degree in 1976 
from the University of Wisconsin at Madison, and 
earned a PhD degree in 1979 from the Massa- 
chusetts fnstrtute o1 Technology. Dave served as 
a weather observer in the U .S. Air Force from 1 963 
to 1 967, attaining the rank of sergeant. Bom in Bar- 
ron. Wisconsin, he is married, has two boys and a 
girl, and resides in Fort Collins, Colorado His hob- 
bies include weight lifting and taking karaLe lessons 
With hjs children. Dave says they hotd advanced 
belts m the martial arts, buthe's stils working on the 
basics. 
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Frank J. Perezalor>so 

a Frank Perez alonso 
specializes in hardware de- 
sign engineering and 
analog ctrcuit dessgn ana 
measurements. He Jomed 

, H P La bo rato r ies in 1 984 as 
a semiconductor process 
technician, and ^s now a 
member of the technical 
staff of HP's Circuit Tech- 
notogy Group. He worked on the electrical charac- 
Sensation of the high-performance HP 406C PGA 
in leg rated circuit package. In the past, Frank was 
involved in E-beam lithography process develop- 
ment, evaluation and test of HP's membrane probe 
card, and test methods for the electrical characteri- 
zation of 1C packages. Before he joined HP, he 
worked on semiconductor processing for Fairchsid 
Semiconductor Corp, and as an instructor in math^ 
physics, and semiconductor processing at Foothill 
College in Los Attos. Ca^ilomia. He studied 
semiconductor processing at Foothill College, re- 
ceived a BSEE degree in 1 985 from the University 
of Santa Clara, and expects to receive his MSEE 
degree in December. Born in Managua, 
Nicaragua, Frank is married, has a daughter, and 
lives in San Jose, California. He enjoys sports and 
teaching. 
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Ghee K. Chow 




Manufact u r i n g deve lop • 
ment engineer Chee Chow 
specializes in computer- 
^nteg rated manufacturing, 
manufacturing data bases, 
and analog and microwave 
circuits He joined HP's 
Santa Oara Technology 
\ Center in 19S4 and has 
i done research in statistical 
Circuit simulations lor circuit designs He recentfy 
transferred lo HP's Microwave Semicondudor 
Division. In the past, Chee worked on bipolar high- 
speed circuits at HP; and researched coal conver- 
sions and materials at Washington State University, 
where he received his PhD degree in 1 974 in phys- 
ical chemistry. He aiso earned an MS degree in 
19S4 in electrical engineering from Oregon State 
University. Chee is the author of 1 5 technical arti- 
cles on fuel processing, physical chemistry, and 
electronics. 




As manager of computer 
flutd dynamics applications 
at Cray Research, Inc.. 
Kent Misegades collabo- 
rated with HP on airflow 
simulation in the HP 9000 
Model 6S0 computer At 
. Cray Research, he fs re- 
sponsibte for a^ fluid 
I dynamics-reJated applica- 
tions in the aerospace, automotive, metals, elec- 
tronics, and chemical industries. His experience 
afSQ includes work as an aerodynamicist for Dor- 
mer GmbH in West Germany from 1980 to 1984. 
A member of the AlAA, Kent's professional in- 
terests include aircraft design and fluid mechanics. 
He IS a graduate of Auburn University with a BSc 
d eg ree n 979) i n mec han ic a I engi neering . an d has 
an ME degree ( 1 9B0) in lluid dynamics from the von 
Karman Institute in West Germany. Bom in Los 
Angeles. California, Kent is mar ned . has three chil- 
dren, and resides in Eagan, Minnesota, His hob- 
bies include aircraft design and radio-controlled 
sailplanes. 




-^-^ ^ 



Vtvek Mansingh 

^ Since pining HP's Systems 
I Technology Division in 

19B7, Vfvek Mansingh ha5 
I performed research and 
I development in thermal 
I management of eleclronio 
I equipment in the com- 
I pany's mainline systems 
I fab. Using finite-element 
modeling, he analyzed 
three-dimensional air How in the HP 9000 Model 
850 computer, Before joining HP, Vivek taught at 
Lehigh University Irom 1 986 to 1 987. A memberof 
the ASME. the I EPS, and the CHMT. he has au- 
thored or coauthored 12 technical publications on 
thermal (luids, and <s named an rnventor on a pend- 
ing patent He earned his MS and PhD degrees in 
1986 Iram Queen's University in Canada, studying 
mechanical engineering and speciaSiztng m ther- 
mal fluids Born in Fatehpur. India, Vivek !S married, 
has two children , and lives in Sania Clara, Califor- 
nia. He enpys traveling with his family and singing 
Indian music with a professional group His 
hobbies include jogging, tennis, and badminton 
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26.5-to-75-GHz Preselected Mixers 
Based on Magnetically Tunable Barium 
Ferrite Filters 

A new resonator material — barium ferrite — and a new four- 
sphere design are featured in a series of magnetically 
tunable preselection filters for the millimeter-wave 
frequency range. 

by Dean B, Nicholson, Robert J, Matrecl, and Michael J. Levernier 



THE NEED FOR HIGHER PERFORMANCE has driven 
the frequency ranges of systems and cornponents 
from the microwave range (under 30 GHz) into the 
millimeter wavelengths (30 to 100 GHz), Moving to higher 
frequencies makes it possible, for example, to increase the 
antenna gain of small reflectors and to improve the spatial 
resolution of imagers. The benefits of the move to milli- 
meter-wave bands are being felt in many fields, especially 
communications* remote sensing, and defense.^ 

The spectrum analy^.er^ a calibrated receiver with vari- 
able resolution, is an important basic tool for testing and 
troubleshooting such systems. Microwave spectrum 
analyzers use advanced technology to provide accurate, 
unambiguous frequency-domain measurements. Hewlett- 
Packard has extended these measurements into the mil- 
limeter-wave bands, 

A new series of preselected spectrum analyzer RF sec- 
tions, the HP11974 Series preselected mixers, makes milli- 
meter-wave spectrum analyzer measurements faster and 
easier by removing image and multiple responses from the 
spectrum analyzer display, thereby eliminating ihe need 
for complicated signal identification routines. Each RF sec- 
tion consists of a mixer to down-convert millimeter- wave 
signals into the intermediate frequency range of HP micro- 
wave spectrum analyzers, and a magneticaily tuned pre- 
selection filter to remove unwanted signals. The preselec- 
tion filter uses barium ferrite resonator material, doped so 
that it starts resonating at the beginning of tht? waveguide 
band (see article, page 59). 

Table ( lists the four preselected RF sections and their 
frequency ranges. Each RF section covers a full waveguide 
band (±20% bandwidth), one of the four standard bands 
from 26.5 to 75 GHz. 

The HP 11974 Series preselected mixers are compatible 
with the HP 85B6B spectrum analyzer, the HP8563A port- 
able spectrum analyzer, the HP 70000 modular measure- 
ment system with the HP 70907B external mixer interface 
module, and other HP microwave spectrum Hnalyzers. 
They provide a displayed average noise level at 10-H?: 
bandwidth that is lower than -106 dBm in the A, Q, and 
U bands and lower than —95 dBm in the V band. Image 
rejection is better than 55 dB in all four bands. 



Table I 

HP Millimeter-Wave Preselected 

Spectrum Analyzer RF Sections 

(HP 11974 Series Preselected Mixers) 



RF Section 

HP11974A 
HP11974Q 
HP 119741] 
HP 11974 V 


Waveguide 
Band 

A 

Q 

IJ 
V 


Frequency 
Range 

26.5 to 40 GHz 
33 to 50 GHz 
40 to 60 GHz 
50 to 75 GHz 



Methods of Extending the Frequency Range 

There are three principal ways to extend tlie frequency 
range of a microwave spectrum analyzer. The first method, 
shown in Fig. la. uses a classic superheterodjme receiver 
front end. A tracking preselector and a local oscillator (LO) 
both sweep the same frequency span, separated by the in- 
termediate frequency (IF). The preselector prevents spuri- 
ous responses, such as images or intermodulation products, 
from being displayed. The l^O must be phase-locked and 
have reasonably low phase noi.se. To use this method, high- 
Q resonators and active devices maintaining negative resis- 
tance across the full waveguide bands would have had to 
be developed. The design would have been intricate and 
expensive. These technological difficulties eliminated this 
method from consideration for the HP 11974 Series. Fig, 
2 shows where this type of millimeter- wave extender 
would interface with the mainframe microwave spectrum 
analyzer. 

A block down-converter, shown in Fig. lb, eases the 
local-oscillator problem by using one fixed oscillator per 
band instead of the swept LO of the superheterodyne re- 
ceiver. With this down-converter, input RF frequencies are 
converted to an identical but lower frequency span (swept 
IF). The swept IF can be arranged to be within the range 
of the microwave spectrum analyzer. Even though the res- 
onator and the active devices are operated at a single fre- 
quency, designing for performance and cost still poses a 
formidable problem. Also, this method lacks a tracking 
preselector, so the first mixer is subject to distortion caused 
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Tracking 
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Preamplifier 
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(b) 



Harmonic Mixer 



RFIr) 

50 to 75 GHz 






, , IF Out 
Vi> 321 MHz 



. LO In 

^ 3.54 to S.33 GHz 



Tune Ramp 

Fig , 1 , 7/1 ree types of RF sections for ex tending the frequency 
range of s specifum analyzer J fie letters A,B, C. and O refm 
to Fig 2, wtucii sfiows wiiere tf^ese RF sections conriect to 
tfie spectrum analyzer, (a) The superheterodyne RF section 
uses a swept preselector and a swept local oscillator (LO). 
J he phase -locked loop m used to set the beginning of the LO 
sweep accurately- (b) The block down-converter has a fixed 
LO and a swept ir^terrnediate frequency (IF), (c) The harmonic 
msxer version of the superheterodyne RF section 



by multiple signals and even single input signals- The wide 
span of the IF tian cause another problem. It requires a very 
wide-bandwidth IF amplifier to improve the sensitivity of 
the microwave analyzer, which is used as a variable IF strip* 
l*he preselected harmonic mixer version of the super- 
heterodyne front end, shown in Fig. Ic, provides a reason- 
able compromise. The preselector protects the mixer from 
spurious responses. The mixer, a harmonic type, uses a 
niilli meter- wave harmonic of the existing microwave LO 
in the analyzer. The conversion loss of such a harmonic 
mixer exceeds that of the fundamental harmonic mixer 
shown in Fig* la, but the design effort goes into the preselec- 
tor* which is a passive component and therefore somewhat 
easier to design than a miliimeter-wave LO. [Of course, 
once the resonators for such a preselector are available, a 
wideband oscillator may be possible if the active devices 
can be obtained.) 

Block Diagram 

The method of Fig. Ic was chosen for the HP 11974 
Series preselected mixers. Fig. 3 shows the HP 11974 block 
diagram. The RF signal that is to be down-converted to IF 
enters the waveguide flange of the tunable preselector 
shown in Fig. 3, then goes to the isolator and the HP 11970 
Series harmonic mixer. Electromagnets in the preselector 
develop a magnetic field, which tunes the preselector. The 
scaling electronics transforms the tune ramp voltage of the 
spectrnm analyzer into magnet current. 

The unbiased hartnonic mixer was developed previ- 
ously^ to extend spectrum analysis into the millimeter- 
wave range. If used without a preselector, the mixer con- 
verts the RF signal to an IF whenever an LO harmonic 
sweeps past the RF, How^ever. the horizontal frequency 
scale is only calibrated for a single harmonic of the LO, 
the 14th for the V-band example shown in Fig, 4a, The 
desired response, the 14+ signal in Fig. 4a, appears as a 
result, as do several unw^anted responses resulting, for 
example, from the 12th, 16th, and higher harmonics. 

In the spectrum shown in Fig. 4a. the RF input consists 
of several signals from the frequency comb of a multiplier 
with outputs every 5.1 GHz. The unpreselected harmonic 
mixer shows several unwanted responses to each comb 



Harmonic 

Mtxer 
n = 1.2,3,4 
Microwave 
(0) Preselector / (a) 32T-MHz 

IF 



RF fnput ,0 
2 to 26 GHz'^^ 



21 -MHz 

IF Detector 



> fi f5Hj^ N_>^ 



2 to & GHz 
LO 




Sweep 
Ramp 
Generator 



Fig. 2. Microwave spectrum ana- 
lyzer block diagram, showing inter- 
face points (A, B, C, D) with the 
millimeter-wEve RF sections shown 
in Fig t. 
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Fig, 4. (a) An unpreselected spsc- 

tium analyzer sweep from 50 to 
75 GHi for an mpul Sfgnal consist- 
ing of comb lines from a nnuitipiier. 
Tfiere are severai unwanted re- 
sponses to each comb tine. The 
harmonic responses to the 51- 
Gi^z comb Itne are labeled, (bj A 
preselected spectrum analyzer 
sweep for the same input signal. 
The multiple responses are elimi- 
nated and the multiplier connb 
lines every 5.1 GHz are clearly 
displayed. 
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line, thereby producing many responses, most of which 
are unwanted and severely hamper measuremenls. 

The HP 11974 preselected mixers add a waveguide track- 
ing preselector to the harmonic mixer. The resulti ng V-band 
display is shown in Fig. 4b. Here, only one response occurs 
for each of the five comb lines. 

Hexagonal Ferrite Filter Design 

Having decided to design the HP 11974 Series by adding 
tunable bandpass filters as preselectors to the HP 11970 
Series un preselected harmonic mixerSt we looked for the 
easiest way of doing things to make the best use of our 
resources. At the o nisei, we had decided to use doped 
hexagonal ferrite spheres as filter resonator elements. Their 
built-in frequency offset (see article, page 59) allowed 
US tcj employ existing Y[G tuning magnet designs to cover 
waveguide band widths. Because the HP 11 970 mixers have 
TEjg waveguide inputs, and because it seemed extremely 
difficult to reduce typical YIG filter loop coupling struc- 
tures (Fig. 5) to the small sizes that would be required to 
make filters for the highest-frequency band (50 to 75 GHz], 
we decided to use TEi^j waveguide as the transmission 
medium in our filter. 

The high-frequency (53 to 80 GHi=) barium ierrite filter 
work done hy Lemke and Hoppe'^ served as a starting point 
for our filter design. Their two-sphere. Iris-coupled filter 
used crossed input and output waveguides (Fig. 6) and 
produced RF magnetic fields in the Irwo w^aveguides that 
were perpendicular to each other at the iris to reduce out-of- 
band leakage. A linear taper was used to reduce the height 
of the w^avcguide to allow a smaller gap between the magnet 
poJe tips- 

A two-sphere filter w^as built in U band (40 to fiO GHz) 
to demoriKtrate the feasibility of the crossed waveguide 
filter approach,'* This filter had typical insertion loss of 4.5 
dB, a 3-dB bandwidth of :J25 MHz. and off- resonance iso- 
lation greater than 30 dB. The spheres were aligned on 
beryilia rods, w^hich were slipped into holders that allowed 
±0.1 mm of sphere adjustment from side to side and up 
and down in relation to the iris. The sphere rods were 
inserted through the reduced-height sidewall of the 
waveguide so that it was possible to center the spheres 
exactly over the iris and to move them closer together or 
farther apart to change the sphere-to-sphere coupling. In 
Fig. 7, the response of this filter is showm centered at ap- 
proximately 46.5 GHz ^ind moved up by 4,5 dB so the 
off -resonance isolation can be read easily off the plot. 

The low-frequency side of the filter's response cuts off 
more quickly than the high-frequency side, and 650 MHz 
away from the peak of the passband the rejection is about 
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YiG Sphere 




^ RF Out 




Magnetic 
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Fig. 6. TVi^o-sphere waveguide bandpass filter. 

35 dB. The rejection of a filter 650 MHz away from the 
peak is important for preselection applications because the 
IKs used in the HP instruments are approximately 310 MHz 
and 321 MHz. An unpreselectcd mixer will display an 
image signal at the same ampMtude as I he true signal at 
two times the IF away from the true signal. Therefore, much 
of a filter's usefulness depends on its image rejection, 
which is a measnre of how much this unwanted trace is 
suppressed. By adjusting the spheres farther apart or closer 
together^ and by changing the iris diameter and the sphere 
size, the best compromise between filter insertion loss, image 
rejection, and off -resonance isolation can be achieved. 

Two-sphere filters were built in the other millimeter- 
wave bands using the information obtained from the U- 
band filter and applying appropriate scaling factors. The 
results for insertion loss and off-resonance isolation for the 
family of two-sphere waveguide filters^ are showm in Figs. 
8 and 9, respectively. The 3-dB bandwndths of ihese filters 
were 200 to 350 MHz. Although the insertion loss results 
were acceptable, the image rejection and off-resonance iso- 
lation of these fihers were nol sufficient for instrument 
applications. The goal w^as then changed to design a filter 
with off -resonance isolation and image rejectioo greater 
than 55 dB. 

A literature search showed three-sphere and four-sphere 
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Rg. 5. A single siage of a typical YtG fitter. 
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Fig, 7, Two-sphere U-band filter response 
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Fig, 8, Insertion loss of two-sphere Mers. 

waveguide filter designs, but none of them would give the 
required off-resonance isolation at millimetor-wave fre- 
quencies. Our next design consisted of two of the above 
twO'Sphere filters under one set of magnet pole tips, con- 
nected by a very short transverse waveguide (Fig. 10), This 
four-sphere filter configuration does not increase the mag- 
net pole lip separation, but in theory should double (in 
dB) the insertion loss, off -resonance isolation, aiid image 
rejection of the two-sphere filters previously built. To 
simplify the mechardcal design, sphere mounts were 
machined from low-dielectric-constant plastic and epoxied 
over the irises. Resonator spheres were then placed on the 
sphere mounts, aligned and epoxied in place {Fig. 10). This 
sphere mounting technique allows accurate measurement 
of the sphere separation after mounting to determine 
s p h or e - 1 o-sph er e co u p 1 1 rig . 

The one significant difference that was expected in going 
to the four-sphere design was the possibility of the two 
irises and the short transverse guide (one wavelength long 
at approximately 80% of band) forming a coupled-cavity 
bandpass filter that might give a fixed- frequency spurious 



Fig. 9. Off-resonance isolation of two-sphere filters. 

response. When the first four-sphere filters were turned 
on, they gave the expected double (in dB) off- resonance 
isolation, insertion loss, and image rejection, as well as the 
cavity-mode response (Fig. 11), By narrowing the width of 
the input and output waveguides and moving the spheres 
off-center towards the center of the filter, the one- 
wavelength cBvity mode can be pushed 5 to 6 GHz above 
the top frequency in the band. The one- wavelength cavity 
mode can thus be eliminated by shortening the transverse 
guide. How^ever, this brings the one-half-wavelength cavity 
mode in-band at about 15% of the band. The one-half- 
w^avelength cavity mode is not as strong as the one- 
w^avefength mode, and can be suppressed very well (Fig. 
12) by introduction of a distributed loss in the transverse 
guide to detune the cavity. This loss is effected by a thin 
sheet of Kapton (plastic) betw^een the sides of the transverse 
guide and the iris piate to allow some energy to leak out. 
The Kapton sheet is shown in Fig, 13. which also shows 
the four-sphere filter assembly. 

Four-sphere filters using scandiunvdoped barium fer- 
rites as resonators are presently being built in A, Q, U. and 
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Fig. 10, Four-sphere fffter design. 
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Fig, 11, First four-sphere fitter response shows cavfty mode 
resonance. 

V bands. They typically have insertion loss of 8 to 12 dB, 
3-dD bandwidth of 120 to 200 MHz. image rejection greater 
than 55 dB. and off-resonance isolation greater than 70 dB. 
These performance figures represent trade-offs that were 
made between the different parameters. For instancBn by 
mnunling the spheres closer together (top to bottom) a four- 
spliere V-hand filter was made having 4 to 6 dB insertion 
loss across the band. Unfortunately, because of the tighter 
sphere-to-sphere coupling, the filter skirts ivere wider and 
the Image rejection was degraded. 

Filter Drive Circuitry 

For proper system operation, the barium ferrite filter 
must track the input frequency of the spectrum analyzer. 
The HP 11974 Series preselected mixer receives a tune- 
ramp voltage from the spectrum analyzer that is propor- 
tional to the frequency of the spectrum analyzer's first local 
oscillator. For any given band, assuming a certain harmonic 
number, mixing sense, and mixer IF, this voltage is suffi- 

Ref 0,0 dB, 10.0 dB' 




cient to determine the millimeter*wave frequency to which 
the spectrum analyzer is tuned. This voltage is then con- 
verted to a coil current that will tune the filter to the appro- 
priate frequency. 

To provide the correct current to the filter, the frequency- 
versus-coil current characteristics of the filter must be taken 
into account. The frequency of the barium ferrite filters 
varies linearly with current, and a straight-line approxima- 
tion is sufficient. For example, a V-bajid filter typically 
deviates from a straight-line tuning equation by no more 
than ±90 MHz over the entire range from 50 to 75 GHz. 
Small tuning non linearities are compensated by using the 
preselector peak function of the spectrum analyzer. This 
function provides a small offset to the tune voltage to peak 
the filter on the signal being measured. 

Because of the internal anisotropic field of the barium 
ferrite spheres, very little current is required to tune the 
filters to the lowest frequency of the band. For all four 
bands, from 26.5 GHz to 75 GHz, the coil current required 
at the lowest frequency is approximately 70 milliamperes. 
The filters then tune to higher frequencies at a rate of fiO 
to 70 GHz/ampere. As a result, the widest frequency bands 
require the most current. The A band, with a span of 13.5 
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GHz, typically requires 270 miliiamperes of coil current to 
tune to 40 GH^, V band, with a span of 25 GHz, typically 
requires 425 mill iampe res of coi] current to tune to 75 GHz. 
Coil current is provided by a 50* volt power siipply. The 
coil current flows through the filter coil, a transistor that 
controls the amount of current flow* and a 3.1 Q resistor 
that is used to monitor the current flow, as shown in Fig. 
14. To minimize the temperature dependent tracking er- 
rors, the 3.10 resistor has a low temperature coefficient, 5 
ppm.'^C. as do resistors in other critical locations. The 
power supply was chosen to be 50 volts to accommodate 
the voltage drops across all of the above items. The capaci- 
tor across the coil shunts unwanted high-frequency cur- 
rents away from the coil. The Zener diode across the coil 
provides a discharge path for the coil at the end of a sweep, 
when the current through the transistor goes to zero. 

The effect of temperature on the filter's frequency is 
another consideration in filter tuning. Some filters, such 
as the Q-band filter, have very little frequency drift with 
temperature, while others, such as the V-band filter, are 
very sensitive to temperature. With a constant coil current, 
a V-band filter drifts at a rate of +1 K4 MH/j'^C For a tem- 
perature increase of 50°C, the center frequency of the filter 
would increase by nearly 600 MHz. Compensation for the 
temperature drift had to be considered because the 3-d B 
bandwidth of the filter is lypically between 120 and 200 
MHz, and this would mean that an input signal would no 
longer be within the passband of the filter. 

Temperature and Delay Compensation 

Temperature drift is compensated by monitoring the tern- 
peralure at the filter and modifying the tuiil current. A 
thermislpr network is used to monitor the temperature of 
the filter. The thermistor network consists of a thermistor 
composite composed of two thermistors encapsulated in 
epoxy and two linearizing resistors. The thermistor com- 



posite is located in the waveguide portion of the filler as- 
sembly [Fig. 13) and tracks the temperature at the barium 
ferrite filter. The network has a temperature dependent 
resistance that is linear from to lOO'C. The thermistor net- 
work is connected as the feedback portion of an amplifier 
that generates a voltage equivalent to the amount of filter 
frequency correction required. This voltage is then summed 
into the voltage that generates the filter coil current. 

Although the temperature compensation required varies 
from band to band, the filters of each band are very consis- 
tent from unit to unit and across the frequency band. This 
consistency allows the correction to be based on tempera- 
ture only. In the A and Q bands, the filter drifts lower in 
frequenc3^ with increasing temperature, while in the U and 
V bands, the filter drifts higher in frequency with increasing 
temperature. 

Fig. 15 shows the frequency tracking errors of a V-band 
fiJter at OX, 25''C, and 75T. with no temperature compen- 
sation applied. The frequency tracking errors of the 25*^0 
trace represent the deviations from a linear relationship 
between the filter coil current and the filter frequency. The 
spacing between the three traces represents the temperature 
drift of the filter with no temperature compensation ap- 
plied. 

Fig. 16 shows the frequency tracking errors of the same 
V-hand filter with the temperature compensation circuitry 
enabled, The remaining frequency tracking errors fail 
within a range approximately equal to the 3-dB bandwidth 
of the filter. The preselector peak function of the spectrum 
analyzer removes these errors at a particular frequency. 

In addition to temperature effects, compensation must be 
provided for the effect of filter tuning delay. When the 
spectrum analyzer sweeps at a fast rate, the filter, tuned 
by the current through a coil with inductance of about 0,8 
henry, tends to lag behind. This effect is compensated by 
placing a differentiator in the HP 11974 tune voltage path. 
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At slow sweep rates, this circuit has no effect. At fast sweep 
rates, additional coil current is provided to tieip the filter 
keep up with the spectrum analyzer. With this compensa- 
tion applied, the spectrum analyzer can be swept at a 
maximum sweep rate of 40 CHz/second. 

Spectrum Analyzer Compatibility 

The HP 11974 Series preselected mixers Eire designed to 
operate with ihree families of He^vlett -Packard spectrum 
analyzers: the HP 7000(1 modular spectrum analyzer family 
w'ith the HP 7090 7 B external mixer interface module^ the 
rugged, portable spectrum analyzer family includintJ the 
HP 8SB0A, HP 85B1B, HP 8562 A. and HP 8563 A, and the 
HP 8566B, a high-performance R&D bench spectrum 
analy/er. Fig 17 shows the HP 11974 Series and the spec- 
trum analyzers. Older models of these spectrum analyzer 
families can be made compatible by installing a retrofit kit. 

To be compatible with the HP 11974, the spectrum 
analyzer must meet certain requirements. First, the spec- 
trum analyzer must have a first LO frequency range of 3 
to 6 GHz at the proper pow^er level. The nominal power 
level of the first LO output is +14.5 dBm to +16 dBm. 
Second, the first IF of the spectrum analyzer must be com- 
patible with the HP 11974. Each spectrum analyzer men- 
tioned above has a first IF of either 310.7 MH:c or 321.4 
MHzh Finally . the spectrum analyzer must provide a voltage 
output that is proportional to the frequency of the first LO 



of the spectrum analyzer. Each of the three spectrum 
analyzer families has a different definition for the tuning 
voltage provided. Because of this, the HP 11974 has 
switches that are used to identify the spectrum analyzer 
with which it is to be used. For each switch setting, a 
specific gain and offset are applied to the tune voltage so 
that the filter wnll be properly tuned. 

Another requirement for the tune voltage of the spectrum 
analyzer is that it have a variable offset summed in. The 
correct amount of offset to apply at any given frequency is 
determined by the preselector peak function. 

Before operating the HP 11974 with the spectrum 
analyzer for the first time^ tw^o potentiometer adjustments 
must be made. These adjustments match the tuning volt- 
ages provided by the spectrum analyzer to the reference 
voltages in the HP 11974. After these adjustments are made, 
the preselector filter will track very well the input fre- 
quency of the spectrum analyzer. The preselector peak 
function is used to eliminate the remaining frequency track- 
ing errors at any given frequency. When executed, this 
function causes the spectrum analyzer to vary its tune volt- 
age to the HP 11974 and monitor the signal level of the 
marked response on the screen. At the maximum response 
level, the filter has been peaked. The frequency range of 
the preselector peak function is proportional to the har- 
monic number on which the mixer operates. For most of 
the analyzers, the preselector peak range is ±260 MHz in 




Fig. 17. HP 11974AIQIUiV pre- 
selected millimeter -wave RF sec- 
tions with mamfrarr\e microwave 
spectrum analyzers (HP 8563 A. 
HP B556B, HP 70000), 
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Fig. 18. Conversion loss csisbfalton chart iS supplied wtth each RF secf/'on The data s$ entefed 

into the mainframe spectfum analyzer. 
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A band and :t450 MHz in V band. 

Conversion loss data for each instrument is required to 
make accurate amplitude measurements. Each HP 11974 
is shipped with a graph and a tabular listing of its conver- 
sion loss as a function of frequency, as shown in Fig. 18, 
The conversion loss measurements are traceable to the 
United State.s National Institute of Standards and Techno!- 
ogy. Data from I he conversion loss table can be entered 
into the spectrum analyser so that amplitude readings will 
automatically be referenced to the input of the HP 11974. 
In addition to the conversion loss table and graph, a conver- 
sion loss label is permanently attached to the HP 11974 
for reference* 
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Hexagonal Ferrites for Millimeter- Wave 
Applications 

Scandium-doped. M-phase barium ferrite has the 
necessary properties. Crystals are grown and spheres are 
processed and tested in-house. 

by Dean B. Nicholson 



Ferrite spheres are commonly used as resonator ele- 
ments in magnetically tunable bandpass filters. At 
frequencies below approximately 30 GHz, yttrium 
iron garnel spheres [abbreviated YIG, chemical formula 
Y^^Fe50i2l are used extensively in this role. At freqiiennies 
above about 30 GH/^ (the miHimeter-wave region) problems 
become apparent with the magnetic components used to 
tune the YIG spheres. These problems include electromag- 
net heating, tuning nonlinearities, and hysteresis- 

The tuning equation of a YIG sphere.^ applicable with 
H^ parallel to H^, is: 



rr^sonLancc 



(2.8 MHz/Oe)(H,j + HJ, 



(1) 



where H^^ is the applied dc magnetic field and H^ is the 
internal anisotropy field [70 Oe for YIG). Using this equa- 
tion, the maximum usable frequency of a YIG sphere can 
be calculated to be about 64 GHz, assuming that the material 
used in the tuning magnet pole tip has the highest satura- 
tion flux density available (approximately 23 kilogauss for 
a cobalt- iron alloy ).^ The anisotropy field H^, can be thought 
of as a built-in magnetic field that acts along a crystal axis, 
or in some cases a crystal plane. When the anisotropy field 
is parallel to the applied field, it gives a frequency offset 
that reduces the applied dc magnetic field needed for reso- 
nance at a given frequency. 

It was obvious that a new resonator material would be 



K.^25.5 kOe 



at kOe 




5 10 tS 20 

Applied DC Magnetic Field H^ (kO«) 

Fig. 1 , Ferrite resonance frequency as a (unction of dc rnBg- 
nettc held for venous values of the anssoiropy field ^ 



required to maJce tunable bandpass filters to serve as pre* 
selectors for the HP 11970 Series harmonic mixers covering 
from A band [26.5 to 40 GHz] up to V band (50 to 75 GHz). 
Using equation 1, it can be seen that if ferrite materials 
similar to ^TG but with higher H^ could be found, then it 
would be possible to build magnetically tunable bandpass 
filters that cover waveguide bands in the millimeter-wave 
region using moderate magnetic tuning fields [Fig. 1), A 
class of material with this property is the hexagonal fer- 
rites,^ 

Properties of [Hexagonal Ferrites 

Hexagonal ferrites are so named because this class of 
materials has a hexagonal crystal lattice, which produces 
crystals that have distinctly hexagonal shapes (Fig. 2). The 
hexagonal ferrites have a large number of phases. Fig. 3 
compares the parameters of the most important phases 
(there are meny more!) to YIG para meters.^ ■'^^'^" The most 
useful hexagonal ferrites have a property called uniaxial 
anisotropy (Fig. 4), which means that the anisotropy field 
lies along only one axis, which is the C axis for the hexag- 
onal crystal. Hexagonal ferrites are commordy referred to 
by their phase and composition. For example, M-phase 
barium ferrite is BaFei^Oitj. 

The minimum useful frequencies listed in Fig. 3 come 
from three constraints. First, with the anisotropy field 
aligned with the applied field, equation 1 shows that the 
lowest fiequency of resonance is [2,8 MHi^/Oe)(Hyj with 
negligible applied field. Second, the magnetic dipoles in 




Fig , 2. Hexagonat ferrite crystals , 
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Notes: 1. So and Al doping s can be varied continuously^ 

2. Y phase has planar a ni sot ropy, f, = (2.6 iytHz'Oe)(H„(H„+HJ)^'= 
when the anisotropy plane is aligned with both dc and RF fields. 

Fig. 3. Summary of hexagonal ferrite and YIG parameters^ 



a ferrite sphere with the applied magnetic field aligned 
with Hjj will not all line up or 'saturate" until a field of 
at least 477^1^^/3 has been applied. Third, for very high-Q, 
[unloaded QJ ferrites at low frequencies, such as YIG, with 
fif^lds between one and two times 47rM^/3. the effect knowa 
as coincidence limiting** limits the amount of power ihal 
a ferrite device can handle to much less than U dBm. There- 
fore, YIG spheres are generally used witli applied fields 
ahove two times 47rMg/3, For hexagonal-ferrite-sphere- 
tuned devices, this power-limiting effect has not been seen 
at power levels up to 20 dBm for our bandpass filter con- 
figurations and thus should not present a problem for this 
application. 

As Fig. ^ shows, scandium and aluminum dopings can 
be varied arbitrarily in M-phase hexagonal ferrites to give 
the desired H^/^ The scandium-doped M-phase barium fer- 
rite will satisfy the frequency range requirements at the 
lower fTequericies while the aluminum-doped M-phase 
strontium ferrite will satisfy the requirements at the higher 
frequencies. Although it is possible to dope M-phase 
barium ferrite with aluminum to raise its resonant fre- 
quency and dope M-phase strontium ferrite with scandium 
to lower its resonant frequency, in general, the higher the 
doping level the more the Q^j of the resonator is degraded. 
Therefore, dopants and materials aie chosen so that the 




^ 



He 



Fig. 4- Uniaxial anisotmpy in hexagonai fer riles 



least amount of dopant is used to cover a given frequency 
range. 

Other desirable properties of M-phase hexagonal ferrites 
aie that they have high 4'rrMs/3 for good coupling to the 
RF fields, high Curie temperatures for low sensitivity to 
temperature change, and fairly high Q^. 
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Fig, 5, Anisotropy field ciianges with doping Adapted with 
permission from reference 4. 
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Sphere Production and Test 

Once the selection of the M-phase hexagonal ferrites was 
made and it was found that cr>^stals were unavailable com- 
mercially, a cr\'Stal growth program was begun at the HP 
Nficrowave Technology Division. In the literature, hexag- 
onal ferrile crystals are typically grown from a BaO/B203 
flux using slow cooling. We used a slow cooling hi mace 
with multiple small crucibles per run and free nucleatiou 
(no seed crystals) for quick optimixation of charge compo- 
sition and temperature profiles. Now that growth condi- 
tions have been optimised, a single larger crucible is used 
for each gro\\ih run with a larger charge so that larger 
crystals can be grown. The total volume of hquid charge 
in the crucible at the start of crystal growth is approximately 
320 ml. The total weight of crystals obtained from the 
growth is about 70 grams. 

The processing of hexagonal ferrites to spheres is concep- 
tually very similar to YIG sphere processing. Because of 
the brittle nature of hexagonal ferrites, proprietary grinding 
and polishing techniques had to be developed to avoid 
chipping the sphere poles. In addition, a separate sphere 
testing system was developed to test the Q^ of the hexagonal 
ferrite spheres, which must be tested at the millimeter wave 
frequencies at which they will be used. 

Summary 

Because of their high magnetic anisotropy fields, spheres 
made of suitably doped M-phase hexagonal ferrites were 
chosen as resonator elements in magnetically tunable 
bandpass filters. These bandpass filters cover waveguide 
bands above 26.5 GHz and are used as preselectors in the 
HP 11974 Series of millimeter preselected RF sections. 
When no outside supplier of he.xagonal ferrite spheres 
could be found, crystal growth and sphere processing and 



test capabililles were developed in-honse. 
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HP DIS: A Development Tool for 
Factory-Floor Device Interfaces 

The HP Device Interface System provides a deveiopment 
facility tiiat inciudes a hi gii- level Protocol Specification 
Language, a testing facility, and a run-time facility for device 
interfaces that run in an HP-UX environment on HP 9000 
computers. 

by Kent L. Garliepp, Irene Skupniewicz, John li* Frolich, and Kathleen A. Fulton 



EFFrCIENT DEVELOPMENT OF INTERFACES be^ 
tween computers and factory-floor devices can be a 
serious C]liallenge in factory automation projects.^ 
These factory-fioor devices consist of programmable logic 
controllers (PLCs), robots, numerically controlled ma- 
chines, gaugeSx scales, and other devices. The problem is 
that they may come from many manufacturers and may 
have different, proprietary interfaces. 

For a few major brands of programmable controllers, 
there are off-the-shelf communications packages that can 
be purchased. This solution has limited applicabillly if the 
needs vary from what is implemented in the package. 

If flexibility is needed, a customized interface can be 
written. At present, development of specific device inter- 
faces is a time-consuming, exacting, and expensive process 
requiring a fairly high level of expertise. The process gen- 
erally consists of characterizing the device's communica- 
tion protocol and then writing, changing, or enhancing 
programs, subroutines, and test suites. This process is well- 
knoum to all interface developers and creates a slow re- 
sponse to market needs. 

In the long run, the use of communications standards, 
such as the Manufacturing Automation Protocol^ (MAP), 
will eliminate many of the device connectivity problems 
and the response to market needs will improve significant- 
ly. In the meantime, many factory-floor devices exist and 
have long useful lives remaining. Many are simple devices* 
such as gauges wit b simple interfaces, that may never con- 
form to a standard. 

To reduce the cost of developing customized interfaces 
for devices that need them and to shorten the time required 
for such efforts, tools are needed to simplify the develop- 
ment and testing of the interfaces. This is the objective of 
the HP Device Interface System (HP DIS). HP DIS is a toolset 
that helps developers create and test interface.^ between 
computer applications and RS-2 3 2 -compatible factory- 
floor devices in less time than before. The resulting inter- 
faces run in an HP-UX environment on HP 9000 Series 300 
or 800 computers. 

HP DIS offers three facilities to make the development 
and implementation of device interfaces more efficient, A 
development facility provides a high-level Protocol 
Specification Language'^ for defining the communications 
logic, A testing facility provides a test generator, a test 



exerciser, and a device simulator. A run-time facility exe- 
cutes the protocol in real time. Fig. 1 show.s a typical pro- 
tocol development cycle and the use of the HP DIS toolseL 

HP DIS: the Tools Approach 

A diagram of the HP illS system is shown in Fig. 2. The 
three bubbles correspond to the above-mentioned three 
facilities provided by HP DtS, These allow the system de- 
veloper to develop, test, and run device interfaces. 

The development facility is simply a compiler that gen- 
erates a protocol interface. The protocol interface is an 
executable process that forms the central component of an 



Standard l^rocess 



Aii«tyzt 



^^^^^1 



OovetQp 
Protocot 




Corresponding Steps Using HP DIS 

Understand application needs. 

Understand device communication 
protocol and message formats. 



Design protocol interface 
architecture, tunctionalityn and 
modularity. 



Write applicatior^ calls to protocol 
interlace. Create protocol Interlace 
using the Protocol Specification 
Language. 



Create lests using the HP-DJS test 
facility. 



Execute tests using the HP-OIS test 
facility > 



Define the configuration arvd 

execute the protocol interface modules. 



Fig. 1 . The process of creating a device Interface. 
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User^Written 
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Devetopn^nl 



Executabte Protocol 
Inierfaces and 
Stale Tatiles 



TMtmg 
Facility 



Port 
Configuration 



Test 
Results 



Run-Time 
Foofllty 



OoetiifiOfitirtforr 



Fig, 2. HP OlS faciffties. 

HP DIS system. The InpiU tC3 the tiompiler is a description 
t)f the device protocol, written in Protocol Specification 
Language (PSL). PSL allows the user to describe a state 
graph and its associated state table in a high-level format 
[see ' 'Finite State Machine/' page 65). 

Other inputs to tfie development facility are subroutines 
that can be Hnked to the pralot:Dl interface. In HP DIS these 
are called achon routines (see *' Action Routines," page 69), 

The run-time facility provides the execution environ- 
ment lor the protocol interfaces. When the protocol inter- 
face runs, il communicates with ports, other protocol inter- 
faces, and other C programs through HP-UX message 
queues. Using a description of the protocol interface's as- 
sociated I/O ports, the run-time facility manages the ports, 
message queues, process startup, and prDt:es,s shutdown. 




Fig. 3, HP DfS testing facility. 
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Represents an HP-UX 
Message Queue 



F I g . 4 , S reps sn protocol inwrfac e deyehpment using HP Df$ . 



The development and run-time facilities also provide 
the following features: 

■ A contributed library of example protocol interfaces, 
tutorial protocol interfaces, and other helpful tools 

■ The ability to implement user-defined lookup tables 

■ Eight-bit native language support 

■ Access between multiple devices and multiple interfaces 

■ The ability to add and delete protocol interfaces dynam- 
ically in a running system> 

A diagram of the HP DIS testing facility is shown in Fig, 
3, This facility consists of a test generator and a test exer- 
ciser. 

The test generator takes the state table and creates test 
cases. The test cases are fed to the test exerciser, which 
executes each test case by .sending messages to the protocol 
interface under test- The test exerciser attempts to achieve 
each state listed in the state table, for up to 1 00% coverage- 
Optional inputs to the test exerciser are user- written test 
cases. The test exerciser executes a sequence of test cases 
and compares expected results to the results of the protocol 
interface under test. Actual devices or I/O ports are not 
necessary for testing; factory-floor devices can be simulated 
by describing their messages. 

The output of the testing facility includes test case 
documentation and test results. The testing facility also 
provides the following features: 
• Full or partial data tracing 

■ Either menu-driven execution or script execution of test 
cases 

■ Protocol filters to simulate garbled messages, time-outs, 
and expression matching 

■ Notification of percentage covered. 
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An HP DI5 Example 

There are ihree steps in developing an interface (see Fig. 
4). The first step is to describe the interaction between the 
application and the factory-floor device interface. The sec- 
ond step is to specify the device protocol in a language 
that HP DIS can compile. The third step after successful 
compilation is to generate the test scripts and test the logic 
of the developed interface. These sleps are illustrated by 
the following example. 

Describing the Interface. A block diagram of the system 
interfaces for tills example is shown in Fig, 5. The interface 
between the application and the device interface is an HP- 
UX message queue. Read and write subroutines are avail- 
able for the application program developer lo send buffers 
to the device interface and receive buffers from it. These 
subroutines allow^ referencing either the HP-UX message 
queue name or the device application name. The links 
betw^een the HP-UX message queues and the device iriter- 
face are established by the run-time facility through a con- 
fignration file (Fig. 6). The configuration file is used by the 
run-time facility to establish the queues, start the defined 
interfaces, create the links, and configure the ports from 
the port definitions. The configuration process elirninates 
the need for a detailed understanding of HP-UX inter- 
process communication and RS'232 serial port initializa- 
tioB- 

The bnffers pas.sed through the queues must be designed 
to carry the information needed by the device interface* 
The device interface can require the application to pass 
device-specific data dkectly or can translate generic func- 
tions into device-specific data. Device interfaces can range 
from very device dependent to completely device indepen- 
dent. In the latter case more logic will be required in the 
device interface. 



For the sake of simplicity, this example uses the device 
dependent approach. The application outbound buffer con- 
tains a six-byte header and a variable-length data string. 
The application inbound buffer contains a status byte and 
a variable- length data string. 

Specifying the Protocol. One of the methods of specif^^irig 
the protocol is a transition diagram translated into a state 
diagram. This is particularly convenient for translating the 
protocol into a language HP DIS can compile. Figs. 7a and 
7b describe a transition diagram and a state diagram for a 
nontrivia! protocol. This example protocol is based on the 
Allen-Bradley Data Highway 1 protocol, but only exempli- 
fies the major features. This example assumes synchronous 
communication- No new request is sent from the computer 
to the factory-floor device until a previous request is satis- 
fied. 

The computer sends a message (MSG) to the device (Fig. 
7a) and waits for an acknowledgment from the device (ACK). 
The computer then waits for a reply message (Fig, 7b). Each 
message consists of block control characters, a header, and 
data. In the case of a read request, the data field from the 
computer contains the address and the length of the re- 
quest. The reply data from the device consists of the values 
requested. In the case of a write request, the data field from 
the computer contains the address and the values for the 
request. The reply data from the device consists of an inter- 
nal status for the request. 

In the event of a communication failure, either the com- 
puter or the device can reply with a failure message (NAK). 
The protocol interface must also recognize that no response 
(TO) is a failure. Other failure mechanisms are not taken 
into account in this example. 



PLDEF^NmONS 



Application 



FIFO '^ 

Queues ^^ 



Fac^r-Roor 
Device tntedacs 



idle) (Wait) 



FIFO 
Qi^eues 



Q3 



Wrtte 
Process 



Read 
Process 



\ 



Z 



Factoiy-floor 
Device 



Fig. 5. System interfaces for HP DtS example. The queues 
are HP-UX message queues. 



RuntJnifi_Najnne 


= Dsvice_j£X; 


RunUme. File^Name 


- ''useFS,1estlDevtcej(x 


Runbmfl_Typ& 


= P; 


Runtime.pfjority 


= 51; 


PcifLName 


= AB; 


PORT_DEFJNmONS 




PorLName 


= AB: 


PofLMaior_# 


- 1. 


Port_Minor_# 


= 4; 


Baud_Rate 


- 9600; 


Ctiaractef^Siie 


= S: 


ParllY 


= N, 


Stop_Bits 


= 1: 


Reati_Type 


= BCC_AB; 


Outpul OiieuQ 


= Q2; 


InptiLQueue 


- Q3{Deviice_xx)- 


QUELfE_DEFCNmONS 




Qg§ue_Name 


= Q2,Q3,Q4,OS: 


Queue.Link 




05>Deviice_)cx; 




Dev»ce_Kx > Q3; 




OA> Device jtK. 




Device ja-;: Q2; 





Fig, 6, Device interface configuration file. 
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Finite State Machine 



Hie finite state machine model has been used in such diverse 
disciplines as computer design, neurophystofogy. lingyistfcs. au- 
tcjcnaia theory, and communications ' The finite state machine 
model IS a natural way to describe systems that process stgnafs. 
This mode! is particufarly convenient for specifying how mes- 
sages are processed in device protocols 

Two standard representations used to describe a particular 
finite state machine are the stale table and the state diagram^ 
A state table uses one row for each state and one column for 
each joput, In each box are written the next state and the output. 
The first row of the state table Is usually assigned to the initial 
stale of the machine. 

A slate diagram is a directed graph in which each arc is labeled 
with the input that causes the transition and the output that is 
generated when the transition is triggered 

A classic example is a parity checker. This machine takes an 
jnput stream of bits of ones and zeros. For each input bit the 
machine produces an output indicating whether the entire input 
sequence so far has even or odd parity The state table and 
diagram are shown in Rg. 1 

The HP DIS state table, written in PSL. is shown below. The 
initial, or home, state is have.even. When an event is triggered by 
the receipt of a or 1, the protocoi interface prints a message 
using the user action routine ceiled U1 , 

Events 

zero„recd : response : 0; 
on&_fecd : resiponse : 1 ; 

States 

rkave_even : Home; 

Stale_Table 

have„even : zero^recd : 
Ulf print even") 
: have_evon- 

have^even : one_reod : 
U1( print odd") 



have_odd : zercuecd : 
Uir print odd') 

: have_odd; 

tiavejodd : one^recd : 
U1 ("print even") 

: have_even; 



State Table 



have_odcl 



State Diagram 
2tro_recC "print even" 



iero_fecd 


Qn«_recri: 




fiave_eveni. prtnt even" 


have_odd, "prSnt odd" 




havB_d-dd. print odd" 


havff__evpn. print even' 



one^recd, "prlnl odd" 



2efo reod, "print odd^' 




one_recd, "prf nl everi^' 

Fig. 1. State table and state diagrBm for a parity checker. 



References 

1 P Ofinr.mg. J Dennis, and J Qyal^tz, Machines, Languages, and CrnDpittBtion, 
Prensice-Hatl, 1978 

2 AS. Tanenbsurn, Compute Nerworhs. Second Editfon, Preniiioa-Haii. 19Sfl. 



Figs. 7a and 7b show state diagrams derived from the 
transition diagrams. The states and events form the logic 
of the protocol interface. Actions (or funciioiis) are per- 
formed at each state-event pair. Fig. 7a also shows an event 
[retry exceeded) that is not supported by the transition 
diagram. This event is added to prevent endless looping. 

A message from the device to the computer [Fig. 7b) will 
cause a reply message event, which would normally return 
directly to the IDLE state. This example will check the integ- 
rity of the byte stream by checking the BCC (block control 



character) count and branching to an extra state (CHECK). 
If the BCC count was incorrect, the original message will 
be sent back to the device. If the BCC count was correct 
the message from the device will be returned to the appli- 
cation. The combination of the IDLE state and the reply 
message event is included in case the device sends a mes- 
sage after time-cut processing. If this were not included, 
the wrong message would be extracted from the HP-UX 
message queue during the next transaction. The message 
from the device is simply acknowledged and ignored. 
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State Event 

(DLE Send meysa^e 



IDLE Reply message 



WAIT AGK 



WAST NAK 



WAIT Reply message? 



WAIT rimfi-out 



Table I 
Actions List 

Actions 

Rea d m e s sage I Vt j itt a |> p U ca lion 
B Li i kl cm t gt J i n g b uf f er f ro m 

incoming buffer. 
Send message to device. 
Cloar retry count. 
Increment message number. 
Start timer. 

Read mesisage from device. 
Send Qc: know lodgment [ACK] 
to device. 

Stop timer. 

Read message from device. 

Start timer. 

Stop timer. 

Read message from device. 
Resend message to device, 
increment retr^' count, 
Slart timer- 
Stop timer. 

Read message from device. 
Checlt block control character 
(BCCl 

Stoptimer, 

Send no rBsponse message to 
application. 



WAIT Retry exceeded Stoptimer. 

Se n d com m u n i ca I i a n ^ erro r 
message to application. 



CHECK Message OK 



CHECK Message not 
OK 



Send acknowledgment (ACK J 

todevicK. 
Send reply data to 

application. 

Send acknowledgment (NAK) 

lo device, 
increment retry count. 
Set timer. 



Next 

WAIT 



State Diagram 



Send Message 



Time-Ogt 




Transition Diagram 
Computer Device 

TO 

IISG 



ACK 



Retry Exceeded 



IDLE 



Wiff 



WAIT 



< 



ACK 



NAK 



> 



^ 



m 



State Diagram 



TO = Time-Out 
or No Response 

Transition Diagram 
Computer Device 



Repty Message 



Time-Out 



CHECK 



WAIT 



IDLE 



IDLE 




TO 



i 



Reply Message 



MSG 



ACK 



> 



USG 



TO = Time-Out 
or No Response 



Fig. 7. TranEition and state diagrams for a nontnviai protocof. 
(a) Message from computer to dsvlce. (b) Message from 
device to computer 



WAtT 



The state diagrams of Figs. 7a and 7b are combined into 
one state diagram in ?i^. 8. 

The actions to be performed at each state transition are 
listed in Table 1. With some additional declarations this 
table can be transformed into a Protocol Specification Lan- 
guage [PSL) program that can be compiled. Previous deci- 
sions about the form of the messages from the application 
can be incorporated into the data structures. 

Fig. 9 shows tiie PSL program ready for compiling and 
testing. The compiler not only checks the program syntax, 
bul also tests the reacbybiUty of eHI state.s from/to the home 
(IDLE) state. This check ensures that there are no incomplete 
paths. 



Reply Message 



Sand Message 



Time-Out 




Message OK 



Fig. 8. Protocol stale machine state diagram obtained by 
combining Ftgs. 7a and 7b 



66 HEWLETT-PACKARD JOURNAL OCTOBER 1990 



)Copr. 1949-1998 Hewlett-Packard Co. 



Matching Messages 



One of me fRosf powetfyl feaures of HP DiS is the matching 
process. It IS used for three purposes: for detarminmg whether 
a message matches a request ever\\ or a response event, for 
parsing a message into a structure, and for delimiting streams 
of characters from a port Each use is slightly different from the 
others, but they all have the same matching characleristtcs. 

Through ihe PSL struct description, ihe user defines the tietds 
in a structure that are to be matched AJl vanatiles descnbe a 
length of data When a structure contains a vanable. the data 
from the message is placed into the structure according to the 
ler^gth of the variable Byte and Boolean variables are one byte 
long Integer variables are two bytes long, and real and long 
variables are four bytes long. String variables can be NULL or 
up to 4K bytes long Data from the message ts parsed into the 
structure's fields according to the variabfe lengths. 

Constants and literals are matched exactly. The lengths of 
data types are the same as above, but the message data must 
contain the M pattern that matches the constant Constants or 
literals adjacent to string variables are used for delimiting the 
strings. 

The HP DIS compiler builds a table for each stnjciure describ- 
ing data in each field. The matching process then walks this 
table for each structure, It there are no string variables in a 
structure, theri each byte is easily assigned to a structure fietd. 
There is no ambiguity However, if there are any string variables 
in the structure, then ambiguity branching begins, because string 
vanables can be null or up to 4K bytes long. The maicfiing 
process branches, assigning this byte to both the string variable 



and to the next field This ambiguity is resolved either by the 
next constant or by the end of Ihe n^ssage. 

HP DIS makes the first shortest match, unlike the HP-UX editor 
VI, which maHes a first longest match. For example, if the fields 
in a structure are: 

vaftat5le string slrl 
constant byte trtt ^ B 
variable stnng sir? 

and the message received is: 

aabbBddBd 

HP DIS uses a first shortest match algorithm to parse this as: 

strl - aabb 
btt - B 
str2 = ddSd 



vi uses a first longest algorithm 


The 


vi command typed 


in as; 


&■' ■-..[. ^)B\(.^)/stf1 --I 5tr2-\=2^' 








would result in stri and sif2 matches 


as: 




stf 1 -aabbBdd 








str2 -d 









Testing. The tests, test scripts, and results files can be gen- 
erated aulomatically at compile time with a PSL compiler 
option. The tests are executed from a test script and the 
results appear in several data files: 

■ The action conmiand file contains the test actions to be 
performed, 

■ The comparison results file coti tains a summary of the 
test paths. 

■ The trace data output file contains detailed test flows 
and variahles. 

The test generator walks the slate table and generates the 
actions command file (Fig. lt>j. The test generator starts 
with the first state-event pair in the PSL progttiin atid gen- 
erates commands to trigger the event. The test terminates 
at the state and event in the ECASE statement (last state, 
next state, event of last state). The data fnllo\ving the WURA 
(write to upper-level read area) statement is the equivalnnt 
of a message from ihe application. The data following the 
WLRA [write to lower-level read area) statement is the equiv- 
alent of a message from the device. A te.st case is generated 
for each subsequent state-event pair. The test cases (CASE 
1: and CASE 2;) marked Good and commented out in Pig, 10 
were already successfully executed. Test cases three and 
four were created by a second pass of the test generator 
based on the previous tests. 

The test generator generates cases to trigger external 
events (messages from the application or device) by creat- 



ing a message from the values involved. State-event pairs 
WAIT ACK and WAIT-NAK [Fig, 9) were successfully generated 
because the test generator was able to use the structures 
Reply Ack mid ReplyNak as the basis for triggering the events. 

The test generator genera les cases for internal events 
based on the associated values of the cotistants or variables 
involved. If the values will satisfy the event, the case is 
generated. If not, the case cannot be generated. Each case 
is rechecked on every pass to see if the variables involved 
have been changed in previous test runs. For more complete 
automatic test coverage, the PSL program variables can be 
set to values favorable for test case generation. In some 
cases, the contents of the messages in the actions command 
file must be altered to affect subsequent cases. 

The test exerciser (Fig. 11) starts the interface under con- 
trol of the run-time facility using the test configuration file 
(Fig. 12] and executes the test actions. At the conclusion 
of the test, the interface is terminated and the results are 
stored for examination. 

Fig, 13 shows the comparison results file. The expected 
state-event pairs for the expected results and the actual 
results are always shown. 

If the actual results differ from the expected results, the 
trace data output file (Fig, 14] can be examined to determine 
the cause. The trace data output file contains a detailed 
description of the data flow^ through the state table for each 
case executed by the test exerciser. It shows ail incoming 
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Device read Q 




= 3: 
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Increment 




= 1J 
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Slop.ljmsr 
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By_one 






^ 1 








Calculale 






= 1 








Check 






^2 








DUE 






= lOh: 






STX 






-2fi; 






ETX 






^atj; 






ACK 






^m: 






NAK 






= i5ti: 






Mi^Relry 






= 5; 


r MaxnumbHrotrelnes 


*/ 


NoRespoflse 




= 201 : 


/' Tfme-out relurn status 


7 


HPJD 






= S; 


/' Device idantrfer 


7 


ComErrcn 






= 202: 


r Retry exceeded 


7 


SLatusOK 






= 0: 


/' Message sent OK; 

•■" return status 


7 

■t 


TimeOutVai 




= 30000 .''1000'/; 


r TO value = i s: 


V 










/' teal - 30 s 


V 


Vanables 












byte 


RelryCcMjnT 


= 0; 


r Retry counter 


^ 


byte 


txa=; 






,'* Prcrtocol block check character 


7 


byte 


Status 




= 0; 


r Protocof status 


V 


byte 


dsl 




- 10; 


/■ Pmtocat destinatran device 


7 


byte 


src 




= 0; 


/' PfOtocot source device 


7 


ijyte 


cmd 




= 0: 


r Protocol command 


7 


byte 


sis 




= 0; 


/* Protocol status 


7 


int^er 


ins 




= 1; 


/" Pra^ocot message number 


7 


sUing 


data 




= ■'; 


r OalaWock 


7 


byte 


ResufI 






/* DummyforDciO 


7 


boofean 


BccFlag 


- TRUE- 


f* Ftjnclion for BCC check 


7 


long 


TJmePefiod 


= 0; 


r Timer value 


V 


Sinng 


Text 




= ": 


/* 8it bucket 


7 


/' Structures u&ed to malch messages '( 






struct 


Reply Ack 


- (DLEACK): 






struct 


ReplyMak 


= (DLEf^AK): 






struct 


DalaP^cket 


= ( DLE STX dsl src cfnd sts tns data OLE ETX bccj ; 




struct 


ReqPacket 


(dst cmd data) ; 






stnjct 


Reply Packet 


= (status data). 






Events 












r Event: Event Ty 


ps. Event detinrtion 
request. ReqPacket: 


/ 




send .message: 




rBply_mBssage: 


response, DataPacket; 






ACK; 




resporise. RepiyAch: 






NAK; 




response, RepfyNak' 






timeoLii: 




intemaJ 


TimeParitJd > - 


^ TimeOulVal; 




retfv_exceeded; 


inlflflia 


, RstryCount>= 


MaxRetryi 




ni5g_ok: 




inlgmg! 


. BccRag = = TRUE; 




msg_nok 




inlemal 


. BccFlag - = FALSE: 




States 












(OLE; 




HOWE 


/ 


' Home state 


7 





Slate table 

IDLE: send. massage: 

DciO^Read, App)ic_read_Q, ReqPackel, , Resull)/ 

f START QuM oulgotng buffer V' 

DcMDve(ReqPaci(et dst. DalaPacket.dst) 

DcMove{HP , y , Data Packet, s rc}' 

DcMove(ReqPackel.cmct , Daia Packet .cmd)/ 

DcMove{StatusOK , D ataPacketsts),- 

[>cMi3VB(lns, OalaPackel.fns)/ 

DcMpvB(Re[:tPacket, data, DataPacket.data)/ 

DcOksum{Catcylate, DataPacketdala, "BCCJ^B", DataPacket.bocK 

.'" END Build outgoing buffer V'' 

DclO(Write. Device_Wrile_0, DalaPackel, , . Result|/ 

DcMcKvejO, ReUvCount)/ 

DcCnfr[ Increment, tns, By_one)/ 

DcClockiSlart.Iimer, TimePeriod, TimeOulVal) 
WAIT: 
IDLE reply message; 

DclO(Read, Davice_rBad_Q, Text, , , Result)/ 

DclO[Wnte, Device_Write_0. Reply Ack, , , Result) 

;IDLE; 
WAiT: ACK: 

DcClock(Stop tmer, TimePeriod)/ 

DclO(Read, Device „read.Q, Text. , , Result)/ 

DcC3ock{StarLtlmor, TimePeriod, TimeOtJiVaJ) 

■WAfT; 
WAIT; NAK: 

DcC5Dck(Stop_t!mer, TmePenod )/ 

DcFO[Read. DevJce_fead_Q. TeKt. , . Result).' 

DctOtWrte, Device. Write_Q, DafaPacket, , , ReisuFt)/ 

Dj£ntr{tficrement, Retry Count, By.one)/ 

DcCFock(Start. timer. TrmePerlod. TlmeOutVal) 

:WArr; 
WAR"; reply. message: 

DcClockiiStppJfmer, TimePeriod)/ 

DclO{Read. Oevice_read_Q, DataPacket, , , ResuH)/ 

DcCksum [Check. DalaPackel. dsl, "BCC AB". DataPackeLbcc, BccFlag) 

;CHECK: 
WAfT: Limeout: 

DcClockf Stop timer, TtmePenod)/ 

DcMovefNoResponse. ReplyPackat. status).' 

DclO(Write, Applsc_writa_Q, ReplyPackfiL , . Result) 

;IDLE; 
WAIT: retry. exceeded: 

DcCk>ck(Slopjrmer, TimePenod).' 

DcWoye(Com Error, Reply Paoket-stafus)/ 

DclOf Write. Applic write _Q, ReplyPacket, . , Result) 

:IDLE; 
CHECK; msg..ok: 

DclO(Wrlte. DevJce_Wnte_a, RapiyAck, . , R&sult)/ 

DcMovefStatusOK , ReplyPaoket status).' 

DcMove( DalaPacket.dala, RepfyPacket. data)/ 

DclGf Write. Applic_wme.Q, ReplyPacket, , . Result) 

:IDLE; 
CHECK: m5g_nok,: 

DclO( Write. Device .Write_Q. RepiyNak. . , Result).' 

DcCntr^Jncrement, RetryCouni, By.orw)/ 

DcClock{Start_limef, TlrrtePenod, TimeOulVal) 

:WAJT; 



Fig. 9, PSL (Protocol Specification Language) protocoi program. 
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Action Routines 



HP D!S is shipped wiih a wide variety d routines to ease The 
creation of protocol rnierfaces It a required action routine canrjoi 
be found in the HP DIS action routine library, ttre us&r can wrrte 
a user acnon routine. 

A protocoi interface consists of two components: a finite slate 
machtne and its corresponding interna! tables The finite state 
machine is customized for the HP DIS and user action roulfnes 
The internal tables are: 1 ) an identifier table consisting ot con- 
stants and vahabtes, 2) an event tabie consisting of event IDs 
and event expressions, and 3) a state table consisting of current 
state ID, event ID, action list, and next state ID tuples. 

In the state table Ihe action list specifies HP D!S action routines 
or user action routines. Action routines operate on the vartabies 
rn the identifier table. HP DIS provides a header file. DcTypesh. 
which can be used by user action routines written in the C pro- 
gramming language to simplify parameter passing. 

The HP DIS-suppJied action routines are listed below 



DcBufMod 

DcCksum 

DcGlock 

DcCntr 

DcConvert 

D€De^ay 

DcEncode 

DcExit 

DcFJag 

DciO 

DcLogAd_AB 

DcMove 

DcScan 

DcTablnit 



Buffer modification 

Checksumming 

Timer 

Counter 

Data conversion 

Delay 

Data encoding 

Terminating the protocol interface 

Flag setting 

Input^output 

Address builder 

Move 

Data scanning 

Tabfeinittalization 



DcTal>Scan 
Dt^ufMod 



Table scanning 
Buffer modifrcation 



An Example 

The HP DIS action routine DcCtock activates or deactivates a 
time counting facility, Timer counters are caller-supplied HP DfS 
variables. The HP-UX system fOterval timer rriMEFLREAL fs used 
to update the time counters in real time A SIGalrm stgnal is 
delivered when the system interval timer rTiMER_REAL expires, 
and all active timer counters are updated. Updating a lime 
counter can trigger an event if the tjmer counter exceeds a 
specified time-out value. In the following example the event Time- 
out is triggered when time_courtef is greater than 60000 (60 sec- 
onds). 



Variables 

long tJme_counter: 
Events 

TimeOul : internal^ tinie!_counteJ" 
State_Table 



60000; 



DcClockfl, ttme_counter, 1000) 



tdre : TimeOut : 
OcClod<{2^ iime_countef ) 
: Idle; 



/• Start time counting 



r Time-out deted:ed 
/' Stop time cOLrnling 



messages^ state-event pairs, and values of all variables after 
every action associated with each state-event pair. The vari- 
able values are useful for checking the results of actions 
even when the correct path is executed. 

This example has shown that by using tools and a subsys- 
tem approach, a factory-floor device protocol can be mod- 
ieled and produced. 

Configurations 

Fig. 15 shows various configurations for HP DlS-built 
interfaces. Interface schemes can use ci single protocol in- 
terface or multiple protocol interfaces, These protocol In- 
terfaces can be stacked in series or configured in parallel. 
When multiple devices are serviced, even more choices 
can be made: each device can be serviced by its own dedi- 
cated protocol interface, or multiple devices can be ser- 
viced by a generalized protocol interface. 

Fig, 15a shows the simplest configuration. Here, one pro- 
tocol interface handles one port and one device. 

Fig, 15b shows three protocol interfaces that work to- 
gether. Message processing that Is common to all ports is 
done in the lower-level Pll. The message is passed to the 
upper-level PI2 and P13 for device-specific processing. For 
example, Pit can collect ail messages from multiple de- 



r 


Run-Time Name State Table File Name 


Runtime..Name 


Device jot /users/te5i''Device xx .si; 


r CASE1; *' 




/* Good V 




r Stale 


Comniand "/ 


r IDLE 


WURA^0 12*^000'; V 


{'• End of case 




r ECASE IDLE WAIT 5end_messagB; '<' 


r CASE a; V 




/-* Good ■/ 




/■ Stete 


Connmand- */ 


r IDLE 


WLRA ^D2O■^D0^^^1^J0Oa■£l0O^MO^0O0 7 


," 


■■,00r-.Q2O''.00S..0OO': '• 


/* End o! case 




/* ECASE fDLE IDLE F^ply_message; '.'' 


CASE 3; 




.* Stale 


Command '/ 


IDLE 


WUFIA ^Ota^JQOO-; 


WAIT 


WLfIA ,'\0a0^006': 


r Eixl of case *.' 




ECASE WAIT WArr ACK; 



CASE 4; 

/* Stale Command *.'' 

IDLE WURA 01^^300'; 

WAIT WLRA M320\026'; 

.■* End of case */ 

ECASE WAtT WAIT NAK; 

Fig. 10. Action command file. 



OGTOBER 1990 HEWLETT -PACKARD JOURNAL 69 



)Copr. 1949-1998 Hewlett-Packard Co. 



Test 
Exerciser 



HP-UK Message 
Queues 



01 



fll 



Q4 
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Fig. 11. Testing interfaces. 



vices, perform checksums, and pass them to the oext level. 
This ensures that all messages are acknowledged promptly 
by a dedicated protocol interface, while less time-critical 
functions are handled by separate protocol interfaces. 

Fig. 15c shows three protocol interfaces, each dedicated 
to a port. Device-specific message processing is done for 
each port. The upper-level PI4 directs and organises mes- 
sages before passing them up to tbe appbcalkm. 

A developer can choose where to put cammun functions. 
The performance will be slightly better when the numl>er 
of protocol interfaces in serial is smaller, since fewer mes- 
sages are passed between processes. On the other hand, a 
centralized function may be desirable because it simplifies 
the system design. 

Performance 

An HP DIS system is easier to construct than a similar 
application in C code, but this is achieved with some loss 
of performance compared to C code. In an HP DIS system, 
functionality is split across five (or more) separate HP-UX 
processes. In C code, all the fundi onality could reside in 
a single process. For example, HP DIS port management is 
handled by separate read and write port processes with 



PLDEFINmOWS 



Runtime.Nanne 
Runtime-Type = 



Devtcejot; 



Buntime.Nam© ^ PMDPSS: 

Bunlime Frle.Name = msr/Wn/PMDPSS; 

Runlime.Type - T; 

QUEUE_DEFIN1T10NS 
Queue Name = Qi ,03,03,04.05; 
Queue. Unh 
OS > DeviC9_xx; 
Device_iot > Q3; 
04 < Device-Kx; 
Dewic^ju < 02: 
PMDPSS < 03; 
PMDPSS :■ 02; 
01 > PMDPSS, 

Rg. 12. Test conftguration fiie. 



■ Device Simulator 



Runtime_N-ame: Device. )cx 

E)cecu|ion_Number; 1 Caae_ Number: 1 

Status: Cases identic^ in lile Dewice.^x.tr and h\Q 
Deuice-XJ(.da 

Event Path laKen and Case Status in tile Oevice.jKX.lr: 

[ I DUE :30nd_message, DCIO ;DCMO VE .DCMO VE ; DCMOVE ; DCMOVE DCMQ VE , 
DCMO VE ; DCCKSU M ; DC FO:DCM0 VE ;DCCNTR ;DCCLOCK ; WAIT] 
Case^Status: 

EvenI P0\h l$k&r\ And Case Status in tiJe Dev^e..X94.d'a' 

|l DLE:ser>ct_me&sage. DC PO OCMO VE :DCMO VE : DC MOVE ; DCMOVE . DCMOVE : 
DCM0VE:DCCKSUM;DCI0;DCMOVE; DCC NTR;DCCLOCK;WArT| 
Case.Stalus: 

Executkjn .Number; 1 Case_Numbef: 2 

Stalus: Ga^es td'Bnticat In file Device.xjt.tr and fife 
Device. Jtx da 

Event Palb takers and Case Status in file Devlce.xx.tr; 
[IDLE ;reply message, DC 10 :DClO : I DLE] 
Case-Status: 

Event Path taken and Case Slatus in (ile De»/ice.j:K,da: 
I [OLE :riip3y. message.DCJO ; DCtO ; I D LEj 
Case-Status: 

F[g. 13. Comparison results file. 



Exacuiion .Number: 1 

Case.Nymher: 1 

RunNme Name: Device^x 

Trace.DatsLAvaiEable 

Action.Command: WURA 

Protocol. Message. Trans mission _Elapsed.,7iime: Thu Apr 13 14:33:30 1999 

PrDtQcoJ-Message. Data. Packet: '■^0O'N012\ffl)0 ' 

Status: Tnggered 

State; IDLE 

Event: send message 

VarlabSe.RetnevaLElapsed.Time- Thu Apr 13 14:33:30 19S9 

State . Table_ Variables : 

Rep^yPacket.data = ' ' 

ReptyPacket. status = 

ReqPadket.dsta = ' ' 

RegPachet.cmd = 

ReqPacKet dsl = 10 

DalaPacket.boc ^ 

DataPacket.data = ' ' 

DataPackat.tns = 1 

DataPacitet.sts - 

DataPacltet.cmd - 

DataPackat.src = 

DataPachel.dst - 10 

Text - ' • 

TimePe'flod = 

BccFlag - Tnje 

HesyJt = 

data = " ' 

tns - 1 

sts = 

cmd = 

arc - 

dst = 10 

Status = 

bcc - 

S VS. ERR = 

Status Tnggefed 

Slate: IDLE 

Event: send.message 

Action; DCtO 

Variat3ie_RetnevaJ_EJapsed_Time: Thu Apr 13 14:33:30 1989 

State. Tabte.VariabJes: 

RepSyPacket.data - ' ' 

Rep!yPadcat.5talus = 



Fig, 14. Trace data output fiie. 
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(a> 



(b) 



Application ^B AppriOdtion 



(e) 



Appfieation 



6-Channel 
Muitipjexer 




Fig. 15. Configurations for HP DIS-buf!t interfaces, (a) One 
pfotocol interface handles one port and one device, (b) Three 
protocQi inte f faces work together, (c) Three protocol inter- 
faces, each dedicated to a port, with an upper -tevei interface 
(PI 4) directing and organizing messages. 



connef:ted HP-UX message queues. HP DIS handles the 
message buffering. This decreases development time since 
port configuration and buffer management code does not 
have to be written, However, the performance of this port 
interface will fall short of a similar interface with integrated 
port management functions. 

It \s also relevant that HP DIS is an HP-UX application. 
An HP-UX cell controller, whether written in HP DIS or 
in C, is subject to normal HP-UX timesharing policies, and 
wnil have nondeterminislic response times. With HP-UX 
on HP 9000 Series 800 computers, processes can be run 
under a real-time priority to decrease the chance that a 



process will be preempted. HP DIS uses this HP-UX exten- 
sion. With real-time HP DIS processes, response lime vari- 
ability can be decreased. 

Performance Test Results 

HP DIS performance studies were conducted to answer 
these questions: 

■ What is the performance on HP 9000 Series 300 and 
Series 800 computers? 

■ What is the throughput of an HP DIS interface? 

The flexibility of HP DIS allows device interface modules 
to be configured and combined in an infinite number of 
ways, A simple model was chosen that gives representative 
data invoi ving the major items contributing to performance* 
Fig. 16 depicts a typical configuration. An application 
(PModel] is connected to a device interface module (Pll], 
which is connected to an HP-UX RS-232 multiplexer port. 
The port has a physical loopback connection and all data 
written to the port is immediately read back from the port. 
Each port has one PModeL A fixed-length message is sent 
to the port by a PModel and returned unchanged. Because 
the application program waits for each message to return 
before sending another, only one message is in the loop at 
a time per PModel. Throughput data is averaged over 20 
transmissions for various message lengths using one^ then 



3000 -T- 



^ 2DD0 



Or 



1000- 



2 Ports 



1 Port 



(a) 



1000 2000 

Message Length (Bytes) 



3000 



ApplieationvAppiicatiQn 
(PModel) - 



Multiplexer 




Loopback Ports - 



Fig. 16. HP DIS performance test model for multiple ports. 
PModel is a simulated HP 01 S application. 



2 Ports '^^ 




1000 

Message Length {Bytes) 



3000 



Fig. 1 7. Loopback response tirr^e for performance tests using 
the HP DiS application Pf\4odel on (a) HP 9000 Model 375 
and (b) HP 9000 Modet 832 computers (HP DfS 2.2 on HP-UX 
7.0). 
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two PModels. 

Fig. 17 shows the data throughput of an HP 9000 Model 
375 and an HP 9000 Model 832. both with 16M bytes of 
memory, under the HP-UX 7.0 operating system. The 
throughput in Fig- 17 reflects the transfer of data one-way. 
The curves show the data throughput for one PModel and 
the sum of the data throughputs for two PModels. 

The throughput decreases with message sizes above 1000 
to 1500 bytes because FiP DIS is performing message match- 
ing (see "Matching Messages," page 67). HP DIS matches 
raw b^'te streams to the user's definition of the message. 

Summary 

The Hewlett-Packard Device Interface System, HP DIS, 
is a tool that eases the development of communication 
links between computers and factory-floor devices. Inter- 
faces can be developed more quickly than with conven- 
tional code. Devices can be simulated, and testing is mostly 
automated. Communication links can be scciled, using only 
the routines needed for the application at hand- Through 
the use of this tool, factory-floor devices from many vendors 
can be mixed and matched. 

HP DIS can improve productivity, reliability, develop- 
ment costs, and market response and reduce support costs 
for device interfaces. 
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Measurement of R, L, and C Parameters in 
VLSI Packages 

Developed to verify the electrical models of a 408-lead 
multilayer ceramic package, this measurement technique 
can measure the very small inductances, capacitances, 
and resistances that are typical of high-performance 
packages. It does not require extraction of RLC parameters 
from time-domain reflectometer measurements. 

by David W. Quint, Asad Aziz, Ravi Kaw, and Frank J. Perezalonso 



THE NEED FOR HIGH-PERFORZvlANCE. high-pin- 
coiint IC packaging with a large number of I/O con- 
nections has brought about a project to design and 
characterize a multilayer ceramic PGA [pin-grid array) ca- 
pable of providing up to 320 I/O lines at an operational 
frequency in excess of 60 MHz. Our chaileoge is to produce 
a package that brings the performance advantages of mul- 
tilayer cofired ceramic technologj^ to high-lead-count, high- 
power VLSI circuits. The package currently in development 
will mount a 14-mm-square CMOS t:hip. 

Fig. 1 is a cross -sectional drawing of the package. The 
package contains 12 metallization layers, which are used 
for signal, power, and ground routing, and uses three-tier 
bonding from the chip to the bonding pads on the package. 
The top two bonding tiers on the package are exclusively 
for signal or I/O connections. The bottom bonding tier is 
reserved for power supply and ground connections. The 
signal routing layers provide a stripline enviroJiment and 
there is a ground plane ad|acent to each of the power supply 
planes* 

The pads on the chip are spaced at an effective pitch of 
approximately 110 micrometer.^ fO.00433 inch). We have 
been able to match this pitch on the package by using two 
signal bonding tiers- Power supply connections are divided 
into eight groups for flexibility and noise isolation. The 



chip mounts directly on a copper-tungsten heat spreader 
that is used for heat dissipation. The heat spreader is also 
connected to ground. 

ElectrlcaE Modeling 

The designers of system processing units put cansidera- 
fale effort into system simulations. One of their main con- 
cerns is the amount of noise induced on logic Vqd (logJt: 
Vnn powers the internal circuitry of the IC) and logic GND 
(ground). Another concern is noise on signal lines. Noise 
is caused by power and ground bounce* and by coupling 
of signals from one line to another. The main source of this 
lioise is the familiar Ldi/dt term, which arises from logic 
and I/O driver currents fit) wing in the inductance of the 
package and circuit board conductors. To produce mean- 
ingful simulations, it is necessary to include models of all 
these components in the circuits. The simulations are par- 
ticularly sensitive to the IC package model, since the pack- 
age lead inductance accounts for most of the inductance L 
in the Ldi/dt term for computing power supply bounce. 
The values of the power supply inductances that need to 
be added in the simulations range from about 70 picohen- 
ries to about 0.5 nanohenry. In addition, ground models 

""Bounce" in ground and power supplies retors xo a [efnporary droop or nse in the supply 
voltage caused by large currents drawn by devices osing [he suppi^es 
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Fig. 1. PGA (pm-grid array) con- 
struction detsil {not to scale). All 
dielectric iayers are 0.008 inch 
mick. 
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and signal trace models including cross couplmg need to 
be included in the system simulations. 

Model Verification 

Creation of electrical models for the PGA was facilitated 
by various software tools and by leveraging previous work 
done on the subject. Verifying that these models were cor- 
rect was much more challenging and is the main topic of 
this paper. Models were verified by comparing package 
parameters calculated from the models vvitb measurements 
on an actual PGA package. 

Most high-frequency measurements are done using a net- 
work analyzer or a time-domain reflectometer (TOR). Both 
instruments measure reflections from discontinuities. The 
problem with using a TDR lies in the interpretation of the 
results when the time delay through a discontinuity is short 
compared with the rise time of the propagating pulse. The 
PGA package signal leads consist of stripline transmission 
lines with a signal propagation time between lOU and 200 
picoseconds and a characteristic impedance of approxi- 
mately 37 ohms. Considering the time delay through the 
package, a TDR pulse with a rise time of about 20 pico- 
seconds is necessary to give good resolution- Using such 
a fast rise time, skin effect, dielectric losses, and reflections 
from the test fixture and interconnections distort the reflec- 
tion test signais to such a degree that it is virtual iy impo.s- 
sible to extract an RLC circuit for the package itself. A TDR 
measurement also does not give numbers for first-order 
and second-order mutual inductances and capacitances be- 
tween signal lines. TDRs are especially unsuitable for the 
power supply planes because of the extremely low charac- 
teristic impedances of these planes (5ii or less]. A TDR 
does not have the ability to drive such a low-impedance load. 

Since simulations are done with the HP Spice software 
package using models made up of discrete R, L, and C 
elements, these are the parameters that need to he verified. 
Because TDK or direct measurements with an impedance 
analyzer cannot give this kind of detail, it was deemed 
necessary to develop another measurement tecimique, 
which is described in the following sections, 

Capadlance Measurement 

A typical PGA signal trace structure, including the signal 
wirebond and the PGA pin. is modeled in the passive cir- 
cuit of Fig. 2. This is a useful model for HP Spice simula- 
tions. It can also be approximated in the form of transmis- 



sion lines with Z^ = VL^/C^ and propagation time 
t = VL^C]. The transmission line approach is more dif- 
ficult to apply when the mutual coupling and resistive 
losses are important. This is the case in any IC package 
where a number of I/O lines and internal circuits are 
switching simultaneously. The RLC equivalent is applica- 
ble to any circuit where the time delay of the element is 
less than about half the shortest rise time of the propagating 
signal. In the case of pin-grid array packages, the odd 
geometry gives the device non-TEM properties; for exam- 
ple, the capacitive and inductive coupling coefficients are 
not equal. 

To overcome the shortcomings of traditional measure- 
ment techniques, the following method is used. The R, L, 
anil C values in Fig. 2 are measured using slightly different 
electrical circuits. The only source used is a ramp generator 
and the only detector used is an oscilloscope with a 
matched 500 input impedance. Fig. 3 illustrates the mea- 
surement of a capacitance such as the coupling capacitance 
between the two traces. The use of a ramped inpui signal 
cancels effects of circuit elements that are not under test 
and aids in the interpretation of results. The charging cur- 
rent i(t) defines the voltage across the oscilloscope's chan- 
nel 2 inputs and the unknown capacitance C^ can be calcu- 
lated from 



C. = V^^/[R,,„^,,dVi„/dtl 



(1) 



where voltage is measured at the center time of the Vge^ 
ramp. 

The voltage V^ut is small, but its accurate measurement 
is important to the determination of the parameter values. 
Tiie measurements that must be taken on the oscilloscope 
screen are the slope of the V^^ ramp (dVin/dt) and Vjnax- 
the plateau voltage on V^^^. Matched coEixial cables be- 
tween the instruments and the device under lest introduce 
time delays, but do not introduce any additional factors in 
the equation for C^ above. For example, losses in the coaxial 
cables from the sample to the oscilloscope will introduce 
no error if they are the same length for both channels, since 
the measurement depends on the quotient of the measured 
voltages. The voltage drops across the series resistance and 
inductance in the trace are small, since they are in series 
with the capacitive impedance. The capacitive impedance 
dominates the current, so the resistive and inductive volt- 
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Fig. 2. Passive drcutt model of a 

typical PGA signal trace structure, 
showing typicai trace parameters. 
Nodes T3 ancf T4 are correspond- 
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trace for capaative coupling In- 
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ages can be ignored. In addition, tfee capacitive loading on 
the V^yi side is of little consequence, because the voltage 
being measiured [the plateau top) is essentially constant. 
The capacitance on the V^^^ side will drop oul of the mea- 
surement equation if the time constant Q,ut^cope2 ^^ much 
less than the lest pulse rise time. 

Ck can be measured quite easily at several pulse rise 
times, and the calculated values of C,, can be compared for 
the different measurements. The longest pulses will give 
smaller plateau voltages, increasing the importance of the 
signal-to- noise ratio of the equipment, while the shorter 
pulses will cause the measurement to depart from its true 
value in a systematic way as the parasitics in the test jig 
become more dominant. In the PGA and other common 
packages, there is usually a wide range of pulse rise times 
that give the same answer for the value of the tested ele- 
ment. 

In this and all the other test situations, the test jig param- 
eters must be measured without the package and subtracted 
from the values obtained with the package in place. The 
design of the test jig is important and must include 
matched-impedance lines w ith connections as close as pos- 
sible to the PGA to minimize the parasitics of the test jig. 
Good ground integrity is important, since large parasitics 
can be introduced quite easily. Poor connections are easily 
found using the real-time display of the oscilloscope. Move- 
ment of a poor connection wull produce corresponding 
wiggling of the oscilloscope trace and a poor connection 
can usually be located quickly and corrected. Once the test 
jig and cabling are connected properly, movement of the 
cables should produce no noticeable movement of the os- 
cilloscope traces. This troubleshooting ability^ is another 
benefit of this technique. 

Inductance Measurement 

Inductances are measured by applying ramped currents 
instead of ramped voltages to the traces under test. This is 
arranged by shorting the wirebonds of the PGA traces to 
the PGA ground circuit. This circuit is shown in Fig. 4. 



The input impedance of the signal trace, represented by 
L^ in series wnth R^, is low compared with the effective 
source impedance of the generator and the oscilloscope in 
parallel (Rj5„,JlRs^ope)- so the input current is determined 
solely by the test equipment connected to the circuit. Thus, 
current 1(1) ^ Vg^nft).^,^.^. since the package under test is 
virtually a short circuit. Virtually all of the current from 
the ramp generator flows ttirough the package trace, so the 
voltage V^,nt is determined solely by the trace inductance 
and resistance. Again, if the rise time of Vg^,„ is much greater 
than the time constant of the generator and package in due- 
tante. the voltage across the package quickly becomes 
Vqui = L^dl/dt + Rj^I. The output pulse consists of the sum 
of tw^o components: [1) a flat-topped pulse Uke the one in 
the capacitance measurement, and (2) a ramp proportional 
to the input current. If we separate the two voltages in Fig. 
4, call the inductive voltage V[^. represented by the plateau 
voltage, and call the resistive voltage V,^. the final voltages 
after the ramp can be found from: 



L, = Vi,R™„/(dV«,,/dt) 



R - V R A/ 



(2) 
t3| 



where dV^^Jdt is the slope of the ramp voltage and Vgc„max 
is the final voltage of the V^j^^ step (see Fig. 4). 

The bounce caused by the partial Inductance of the PGA 
ground net can he canceled by driving a third (utu^oupled) 
signal trace, grounded to the shield at the inner lead bond, 
with a negative -going ramp of the same magnitude. The 
third lead must be uncoupled so that mutual inductance 
does not contribute unwanted vol tages to the measurement. 

Test Fixture and Parasitics 

For each of the parameters that we measured (inductance^ 
capacitance* mutual inductance, and mutual capacitance) 
we had to build a different set of probes- The parasitics of 




20 ' 30 
Time (nsj 

Fig. 3. CBpacitanoe measurement circuit arrd vaitage wave- 
forms. 



20 30 

Time (ns) 

Ftg. 4. hduciance measurement drcuil and voltage wave- 
forms. 
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these probes were zeroed out before and after each measure- 
ment to make sure that the characteristics of the probes 
did not change during the measurements. This was espe- 
cially important in the case of the power supply inductance 
measurements because the characteristics of the probes 
were comparable in magnitude to those of the package. 

Signal Models 

Signal trace models were calculated using Stripcal^ to 
calculate the lumped elements in the trace model betw'een 
the PGA bond pad and the base of the pin. Ind3^ was used 
to calculate the inductances (both self and mutual) for the 
wirebonds. The measurements were done on a 408-pin 
PGA that had a test chip mounted and bonded in it. For 
the inductance measurementSt all the wirebonds were 
shorted together on the tihip. For the capatjitance measure- 
ments, all the signal wirebonds %vere isolated. 

Resistance measurements are not discussed in detail be- 
cause they are straightforw^ard and because the measured 
values of the tungsten metallization sheet resistance were 
between 5 and 7 milliohms/square, well below the maxi- 
mum specification of 13 mi Hi ohms/square. In addition, the 
resistance of the ground and power supply routing was 
less than 5 milllohms, which was not considered signifi- 
cant. 

The inductance measurement results were as follows: 



Parameter 

SelfLofVpn 

Sell L of V^ji (group 1) 

SeifLofV,3,Jgroup2) 

SelfCofVjj;3 

Self C of Vol (group!) 

Self C of VyL (group 2) 



Measured Calculated Difference 

97 pH 79 pH 19% 

0.88 nH 0.77 nH 14% 

TlSnH 1.06 nH 11% 

4,9fJnF 4,92 nP 1% 

0,66 nF 0,62 iiF 6% 

0.5 nF 0,47 nP 6% 



Note: Vpp is the logic power supply voltage and Vql is the 
I/O driver supply voltage. 

Vdd Measurement Errors 

In the V] J] J inductance measurements, the to pa log}'' forced 
us to put h\\ eight ground wirebonds on the same side of 
the V|3|3 wirebonds instead of four on each side as the chips 
are actually bonded. Moving all the ground wirebonds to 
one side of the Vpp wirebonds may increase the inductance 
of the wirebonds by up to 50%. This effect accounts for 
most of the difference between the calculated and measured 
values of the V^^^ inductance. Fig- 5 compares the measure- 
ment bonding pattern and the pattern the package was 
designed to use in actual operation. Another source of error 
is the shape (loop height, length, etc.) of the wirebonds. 
The wirebond shape may be turn out to be different from 
the one that was analyzed. 



Parameter 



Measured Calculated Difference 



Self L (upper tier) 


15.1nH 


15.2 nH 


1% 


Self L (middle tier) 


14.9 nH 


14.6 nH 


2% 


Mutual L (middle tier) 


3.64 iiH 


3.21 nH 


12% 


Mutual L (upper tier) 


4.7 nH 


4.5 nH 


4% 


WB coupling (1st order) 


2.0 nH 


2,1 nH 


5% 


WB coupling (2nd order) 


1.4 nH 


l.BnH 


7% 


Note: WB = wirebond. 









The sources of error for the signal inductance parameters 
are: (1) the routing on the chip. (2) variations in the length 
and the shape of the wirebonds and traces, and (3) imper- 
fections In the ground planes. 

The capacitance measurement results were as follov^s: 



Measured Calculated Difference 



10.1 pF 


9.5 pF 


6% 


6.5 pF 


6.3 pF 


3% 


0.7 pF 


0,5 pF 


29% 


0.6 pF 


0.5 pF 


17% 



Parameter 

SelfC (upper tier) 
SelfC (middle tier) 
Mutual C (upper tier) 
Mutual C (middle tier) 



The sources of error in the signal capacitance measure- 
ments are: (1) the capacitance of the pin braze pads, and 
(2] the capacitance of the vias and the associated cover 
dots. The capacitance between the wirebonds and betw^een 
the pins was found to be less than 0,1 pF and has been 
ignored. 

Power Supply Models 

The measurements were done in the same way as for the 
signal traces. The results were as follows; 



n„D, 



"eNDflpo^.g 4eND 



cr 'p^m^ °rf g 



Chip 



i 



Package 



(a) 



4GN^ 4GN^ap„„^ 




D 



Package 



{*>) 



Fig. 5. To measure Vqq inductance, st was necessary to put 

all eighl GNO wirebonds an the same side of the V^d 
wirebonds, as shown in (b), In actual service, the wirebond 
pattern is as shown in (a). This accounts for most of the 
difference between the measured and calculated values. 
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Vdl Measurement Errors 

The wirebpnding pattern may %^ry in the Vqi^ bonds. In 
the calculatioEis for the Vol inductance, we also did not 
take into accoimt the inductance of the epoxy routing on 
the chip. 

The power trace capacitance nieasnrements were done 
without the bypass capacitors because the 0.1 -^F nominal 
valne of the bypass capacitor is very large compared to the 
capacitance parameter that we were tr^'ing to measure. A 
very high degree of correlation was obtained between mea- 
surements and calculations* 

Conclusions 

It is important to be able to verif^^ electricaj models of 
packages used in high -performance systems. Time-domain 
reflectometn^ caimot give the kind of detail needed for 
model verification, and it is very difficult to derive an RLC 
circuit from the results. 

The measurement technique described in this paper^ 
overcomes the problems associated with TDR measure- 
ments. Inductance is measured while capacitance is 
shorted out, and capacitance is measured on open-circuit 
traces so inductive effects are negligible. Slow rise times 
of input voltage pulses make it possible to avoid transmis- 
sion line effects. A feature of this method is that the mea- 
surements can be made with readily available digital oscil- 
loscopes and pnlse generators. 

Good correlation between the calculated and measured 
results for the PGA package was obtained. This measure- 
ment technique has also been used to measure parameters 
of TAB (tape automated bonding) packages, printed circuit 
PGAs. and printed circuit board connectors with good re- 
sults, and could also be useful io other electrical model 
verification experiments. 
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statistical Circuit Simulation of a 
Wideband Amplifier: A Case Study in 
Design for Manufacturability 

Statistical variations of integrated circuit parameters are 
often correlated, not independent. Examples are side-by- 
side resistor values and matched transistor gains. 
Accounting for these correlations using principal 
component analysis can make statistical simulation an 
accurate predictor of manufacturing data. 

by Chee K. Chow 



IN INTEGRATED CIRCUIT DESICN, there is a need for 
statistical circuit simulation that can accurately project 
circuit performance distributions in manufacturing- 
There are two reasons for this need. First, being able to 
project the performance distributions precisely in the de- 
sign phase enhances the chance of a flrsl-pass success. 
Thus, the cycle time from the design phase to manufactur- 
ing release can he significantly reduced. Second, simula- 
tion can serve as a diagnostic tool to identify hidden process 
problems. For example, large discrepancies between the 
simulated and manufactured distributions frequently indi- 
cate process anomalies not previously discovered. 

A simple approach to statistical circuit simulation is to 
perform a large number of Monte Carlo simulations.^ The 
inputs to these simulations are computer-generated ran- 
dom circuit parameters based on tlie means and standard 
deviations of the circuit elements extracted from the man- 
ofacturing data. A significant drawback of this approach 
is that it does not account for the highly correlated nature 
of the device parameters within an integrated circuit die 
and also among dice. Consequently, it rarely gives accurate 
predictions. 

In integrated circuits, device parameter variations are 
separable into two types. Variations across many dice, waf- 
ers, or fabrication lots are random m nature, while those 
within a die are highly correlated. Examples of the latter 
type are the side-by -side layouts of resistors and matched 
transistor pairs. At present, conunercially available circuit 
simulators do not address these intercorrelations, so they 
do not provide the information needed. 

This article describes a circuit simulator study that ac- 
counts for both the intradie device correlations and the 
lot-to-lot random variations. The technique used is based 
on principal component analysis, a branch of multivariate 
statistics. Examples are presented shouting the application 
of this technique to a custom wideband bipolar amplifier 
IC used in the HP 54503 A digitizing oscilloscope. The tech- 
nique was used to set an accurate specification early in the 
design stage and to identify a process problem affecting 
the circuit performance. 



Principal Component Anaiysis 

Consider an integrated circuit having n parameters such 
as resistor values and transistor gains. These parameters 
vary statistically from lot to lot, from wafer to wafer, and 
from die to die because of the time and spatial variations 
of the fabrication process. The manufacturing distributions 
for this IC can be simulated if an ensemble of n- variable 
vectors can be generated having the same statistical vari- 
ation as the circuit parameters. The accuracy of these simu- 
lations depends to a large extent on how accurately the 
intercorrelations of the n variables are accounted for. 

The n-variable vectors can be generated by multivariate 
statistical techniques.^^^ starting from the correlation ma- 
trix of the n variables. Multivariate statistics analyzes the 
structure of complex statistical variables to identify latent 
factors (factor analysis] or the principal components {prin- 
cipal component analysis). A comprehensive treatment of 
this subject can be found in the literature.^^^ Multivariate 
statistics has been used extensively by behavioral scientists 
to analyze Irilent factors responsible for certain behavior 
traits. Its applications to manufacturing problems, based 
on our literature survey, have been very limited, '^^^'^^^ 

One method of solving for the ensemble of n-variable 
vectors is based on principal component analysis tech- 
niques- Briefly, principal component analysis describes the 
variances of the n random variables in terms of a set of 
mutually orthogonal or statistically independent (uncorre- 
lated] variables known as principal components. Each prin- 
cipal component accounts for a portion of the total variance 
larger than the succeeding components. Statistical ensem- 
bles of the n variables can be readily generated from random 
numbers after the transformation to the principal compo- 
nents because of the statistical independence of the princi- 
pai components. 

The ensemble of n-variable vectors is generated in a 
closed-form solution starting from the n-variable correla- 
tion matrix R, provided that the eigenvalues of R are all 
positive and the variables are normally distributed. For a 
set of n circuit variables, y^, y2. --i Vn having a correlation 
matrix R, it can be shown that the ith statistical variable 
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yi is given by the expression :^'^ 



W 



where x, , x^, .... x^ are normally and independently distrib- 
uted random variables (the principal components). The 
values for the Xj in equation 1 are chosen randomly and 
independently. This is possible because the X; are statisti- 
cally independent. 

The Xj in equation 1 are the eigenvalues of R. The /i^ and 
cr^ are the mean and standajd deviation of the ith variable, 
7ii is the jth component of the ith eigenvector of R. The 
statistical measuxes for these variables are obtained from 
volume manufacturing data. 

Circuit Si mutation Algorithm 

A circuit simulator^ was written in C and HP-UX scripts. 
It runs on an HP 9000 Series 370 worlcstation. The algorithm 
of this program is shown in Fig, 1. It consists of three 
modules; 

■ A statistical analysis package performs all the computa- 
tions according to equation 1. 

■ A parser retrieves these correlated vectors and generates 
the HP Spice text files, 

■ HP Spice performs the simulations. 

The user is required to input three pieces of information: 
(1) the HP Spice text file, (2) the correlation matrix of the 
circuit variables, and (3) the means and standard deviations 
of the circuit variables- Data for (2) and (3) has been com- 
piled from volume production measurements for many HP 
fabrication processes. 

The confidence limits of the simulated distributions vary 
as the square root of the number of simulations,^ Based on 
numerous case studies, about 100 simulations are adequate 
to project a 95% confidence limit, even for a fairly complex 
system. Although these Monte Carlo simulations are com- 
putationally intensive, with the emergence of widely avail- 
able high-performance workstation-class computers, they 
can be routinely performed. A typical 200-sample Simula- 
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Fig. 2. Simulauon was used to set the mmimum gainspeafh 

cation for this programmBbie gain circuit portion of an inte- 
grated ampiiffer tC. 

tion takes 149 seconds on an HP 9000 Model 370 worksta- 
tion. 

Case Study 

The merits of this statistical circuit simulator are illus- 
trated by two applications during the manufacturing re- 
lease of a custom high-speed integrated circuit. 

The circuit is an integrated amplifier fabricated using 
the HP5 process, a 5-GHz fj oxide isolation process. The 
IC is used m the HP 545 03 A low-cost, high-performance 
digitizing oscilloscope. This custom IC is the heart of an 
amplifier/attenuator assembly that accurately reproduces 
signals from dc to 500 MHz and from 40 mV to 40V with 
ac or dc coupling and a constant output dynamic range of 
500 mV. The IC consists of nine functional blocks, On-chip 
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1,40 1.45 

Minimum AmpiifieT GaJn 



1.50 
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Fig, 1 . StBiistical circuit simulation algorithm. 



Fig, 3, The distribution of the minimum gain from 220 corre- 
lated simulations has a mean of 144 and a standard devfatfon 
of 04, it predicts a minimum gain specification of 1.33 to 
1.57. 
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registers can program the gain frnm 1.5 to 12.5 in 3% incre- 
ments. 

Projection of Manufacturing Specifications 

In the manufacturing release of this IC, no reliable data 
was available to set the minimum gain specification (1.5 
nominal) of the programmable gain circuitry shown in Fig. 

2. This gain cell can be programmed to amplify small sig- 
nals with a nominal gain of 1.5 to 12.5. 

An inaccurate specification on the minimum gain would 
cause high parametric yield loss. The statistical simulation 
techniques described previously were carried out to project 
the gain distribution in a reaMife manufacturing environ- 
ment* For these simulations, 36 circuit elements were iden- 
tified as random variables^ The correlation coefficients of 
these variables were compiled from production data for 
the HP5 process. Specifically, the following intradie device 
correlations were accounted for: 

■ Correlations between resistors 

■ Correlations betw^een transistor model parameters 

■ Correlations betw^een resistors and transistor model pa- 
rameters. 

A 200-sample Monte Carlo simulation was carried out. 
The simulated minimum gain distribution is show^n in Fig. 

3. It projects a i^3ct specification of 1.33 to 1,57. Measured 
production data for six months shows a distribution with 
a mean of 1,43 and a standard deviation of 0.034 (Fig. 4]. 
The measured data projects a specification of 1.33 to 1,53. 
The simulated and manufacturing statistics are compared 
in Table I. 

Statistical Simulation as a Diagnostic Tool 

A second example of ihe power of this simulation 
technique illustrates its role as a diagnostic tool. The por- 
tion of the IC under study is the dc restore circuit, which 
level shifts the complementary high-frequency outputs to 
the ground level. A block diagram is shown in Fig. 5. From 
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Flgp 5. A portion of the integrated amptifier iC showing the 
operational amplifier and resistor bndge of the tevei shifting 
subcifcuit. The op amp in this dc restore circuit had a large 
}ow4requency output offset for which the simutation data 
did not match the production data, suggesting a process 
anomaly. 



Table I 

Comparison of Simuiated and 

Measured Minimum Gain Distributions 





Simuiated 


Measured 


Mean 


1.44 


1.43 


Standard Deviation 


0.04 


0.034 


Specification 


1.33-1.57 


1.33-1.53 
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Fig. 4. SiX -month production data has a distribution with a 

mean of t .43 and a standard deviation of 0.034 The minimum 
gain specification is 133 to 1.53. 



Fig. 6. Distribution of the output offset of the op amp from 
production data. The mean is -49 mV and the standard de- 
sfiation is It mV. 
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production data, the low-frequency output offset voltage 
of the op amp had been observ'ed to be large. The op amp 
output offset voltage is defined as the output voltage of the 
op amp when the t\%^o high-frequency outputs (inverting 
and noninvertijig) are equal. Under balanced conditions, 
the output offset should be close to zbtq. U was not knowTi 
what the standard deviation caused by process latitudes 
should be. Fig- 6 shows a typical distribution of this param- 
eter from six months of production data. It has a mean of 
-49 mV and a standard deviation of 11 mV. 

The op amp circuitn^ has 22 random variables, of which 
12 are highly matched resistors and ID are the transistor 
model parameters. Correlated simulations were carried out 
as for the first example. A 200-sample simulation revealed 
the distribution of the offset voltage to have a mean of 11 
mV and a standard deviation of 3,4 mV, Such a large dis- 
crepancy between the manufactured and simulated distri- 
butions suggests some hidden process anomaly that has 
not been discovered. 

Subsequently, the process defect that caused this wide 
distribution of the output was identified. The circuit was 
redesigned to desensitize it to the process defect. The dis- 
tribution from one wafer after redesign is compared to the 
simulated distribution in Fig, 7, The redesigned circuit 
shows a mean of 6 mV and a standard deviation of 4.8 mV. 
The simulated values are close to the initial production 
data. The slight discrepancies of the standard deviations 
can be accounted for by a variety of second-order effects 
that were not included in these simulations, most notably 
variations in metal resistivity and metaJ -to -metal contact 
resistance. 
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Conclusions 

This statistical circuit simulation study has demonstrated 
the accuracy of this technique in projecting circuit perfor- 
mance distributions in manufacturing. The technique also 
has a valuable role as a diagnostic tool for troubleshooting 
process problems. Despite some assumptions used both in 
the underiying pri^ncipal component analysis theory- and 
the device modeling* these simulations are accurate enough 
to be a practical CAD tool In product development. 

It is hoped that this approach to design for manufactnxa- 
bilit}\ through synergism of volum^^e production data with 
design simulation tooling as exemplified by this simulation 
study p will be a significant contribution to manufacturing 
technobgy. 
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Fig. 7. (a) The distribution of the output offB^t voltage of the 
op amp from 200 correlated simu!attons has a mean of 11 

mV arid a standard deviation of 3.4 mV, very different from 
the production date shown in Fig. 6. (b) The distribution from 
one production wafer after redesign has a mean ofSnjV and 
a standard deviation of 4£ mV; more cfosefy matching the 
sf mutation data. 
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System Level Air Flow Analysis for a 
Computer System Processing Unit 

Numericat simulation of particle traces using finite element 
modeling and supercomputers gives a good qualitative 
picture of air flow features. Computed velocity profiles and 
pressure drops have reasonably good accuracy. 

by Vivek Mansingh and Kent P. Misegades 



^% TEADY. VISCOUS. THREE-DIMENSIONAL AIR 
^^^ FLOW within a computer system processing unit 
^^ has been analyzed using finite element modeling. 
The objective of the study was to investigate the effective- 
ness of finite element modeling in predicting the air flow 
characteristics within a computer. A full-scale ihree-dimen- 
sional finite element model of an HP 9000 Model 850 com- 
puter was created using FIDAP. the finite element code 
from Fluid Dynamics InlernationaL This mtniel consisted 
of over 60,000 nodes and over 40.000 8-node brick ele- 
ments. Extensive cnmputations were carried out using 
CRAY Y'MP supercomputers. General flow characteristics* 



including velocity profiles and pressure drop across the 
system^ were computed. Numerically calculated particle 
traces were recorded using video equipment. It was found 
that numerical simulation of particle traces can show good 
qualitative features of the flow through the system and the 
modelinj^ results of velocity profiles through the boards 
and the system pressure drop have reasonably good accu- 
racy > 

Project Objective 

For the thermal management of air-cooled computers, 
the key air flow parameters to be determined are the air 
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Fig. 1 * HP 9CW Model 850 computer system proaessfng unit 
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velocities in the computer cabinet and llie pressure drop 
across the system. The air velocity flow characteristics in 
the system help in designing the system layout at the board 
and component level while the system pressure drop forms 
the basis for selecting air movers. Thermal management at 
the component level also requires the knowledge of board 
and component level air flow characteristics. 

Traditionally, pressure drop and flow characteristics 
within a computer cabinet have been experimentally mea- 
sured on protot^T^es of the machines. Unfortunately, an 
accurate prototype can only be available when all the com- 
ponents of a system have been designed. This typically 
happens only tc}wards the end of a design effort. Therefore, 
the flow characteristics and the system pressure drop can 
he accurately measured only after almost ail the compo- 
nents of the system have already been designed. If for some 
reason the pressure drop is found to be excessive or the 
air flow characteristics are found to be different than ex- 
pected, major design changes may have to be made at the 
end of the design cycle, resulting in serious product mod- 
ifications and delays. Furthermore, experimental measure- 
ments m a prototype are both difficult and expensive in 
terms of human effort. 

It would be advantageous to have modeling tools that 
can predict these air flow characteristics early in the design 
process. A model could also easily simulate effects of high 
altitude, zero gravity^ and other conditions. The objective 
of this study was to investigate the effectiveness of finite 
element modeling in predicting the air flow and pressure 
drop characteristics within a comimter. 

Model Development 

As mentioned earlier, a full-scale model of an air-cooled 



HP 9000 Model 850 computer system processing unit (SPU} 
was created. A photograph and a drawing of a Model 850 
SPU are shoum in Fig, 1 . A Model 850 SPU is approximately 
1 m high. 0.7 ra wide, and 0.7 m deep. It has four processor 
boards and several other memory and I'D boards. The back- 
plane essentially divides the cabinet into I wo halves: the 
CPU (central processing unit) side and the L'O side. It has 
six tube axial fans for cooling, which operate in the suction 
mode. Four of these fans are for the CPU side and two are 
for the 1/0 side. The air inlet is at the top and the outlet is 
at the bottom. Detailed mechanical drawings showing loca- 
tions and dimensions of the structural components, printed 
circuit boards, suction fans, flow mlets, and flow outlets 
were used to create the full-scale model of the system using 
FlDAP*s preprocessor FIPREP and mesh generator FIMESH. 
The full model was divided into smaller finite elements 
using 8-node brick elements. Fig. 2 gives a view of the final 
mesh, consisting of 60,507 nodes and 48,600 elements. 

From the outset, it was recognized that detailed three- 
dimensional modeling from the system level to the compo- 
nent level » that is, from the overall dimensions of the 
cabinet do vim to the smallest component on a board, was 
impossible, both from a modeling standpoint and because 
of computation time requirements. For instance, we esti- 
mated that simulating the flow through just one of the CPtJ 
boards having a number of RAM chips. PGAs, CPU chips 
and muitifinned heat sinks would require a mesh of ap- 
proximately 60.000 to 100,000 elements and a run time of 
more than 10 CPU hours. Therefore, it was not possible to 
model every single component in the system. Since the 
main focus for this project was on system level characteris- 
tics, a component level simplification in the geometry was 
made. To model the components on the boards, it was 




Fig. 2. A v^ew of the finite eiBment 
mesti for simuiBtion of f^e air flow 
fn an HP 9000 f\Aodel 850 SPU. 
Th^ connpletQ mestt aonststs of 
60,507 nodes and 48,600 S-node 
bnck efements. 
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Fig* 3. Computed flow velocities 
in the X-Z plane at the entrance tc 
the printed circuit boards^. 



assumed that between any two printed circuit boards, a 
certain percHnttige of the flow passage was blocked by com- 
ponents. Ba.sed an good engineering judgment, for the four 
CPU printed circuit hoards the blockage was assumed to 
represent 30% of the volume between two adjacent boards, 
whereas for all the other boards the blockage was assumed 
to represent 50% of the volume between adjacent hoards. 
Flow deflection vanes at the air inlet of the cabinet were 



included in the model as infinitely thin plates at the same 
angle as the actual vanes. 

Although ihe computational effort required to generate 
this three-dimensional model was moderate, it took ap- 
proximately 114 engineer-months to create the model be- 
ginning from mechanical drawings. It is also important to 
note that the use of computer graphics was essential to the 
successful creation of this mesh, visual a oa lysis of the mesh 
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Fig. 4. Computed flow velocities 
in the Y-Z plane through the 
prmted circuit boards. 
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COMPUTER AIRFLOW AT ASSEMBLY LEVEL - CRAY SIMULATION 
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Fig. 5. Computed flow velocities 

through the system. 



generator's results being the only good means of ckecking 
progress. For this, both FlDAP's postprocessor FDPOST 
and Cray*s Multi-Purpose Graphics Sysleni MPGS were 
used. All computalionSv including graphics, were per- 
fonned on CRAY Y-MP supercomputer systems. 



Boundary Conditions 

The physical problem modeled was three-Himeasionah 
steady, viscous, Uiminar. isothemiai flow. Because the ve- 
locity through the system v^^as of the order of 2 m/s and 
the length .scales of the components were small, the flow^ 
was assumed to be laminar. The flow was assumed to be 
isothermal because the main focus of the problem \vas the 




Fig. 6- Ansmaffon of simulated 
paritclB traces representing the air 

flow. 
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fluid flow characteristics* 

On all solid surfaces of both physical and blocked re- 
gions, a no'Slip velocily boundary condition was specified. 
At the two air flow entrances on the top front and back of 
the cabinet, no boundary conditions were set. For the air 
outlet at the bottom of the cabinett a constant-velocity bound- 
ary condition was defined. However, for I he outlet bound- 
ary condition, not enough information was available ini- 
tially. The flow rate produced by a fan is dependent on 
the pressure drop it experiences. Flaw rates are given in 
tabular or graphictil form as a function of pressure drop, 
The data used in this work was for the fans running at 60 
Hz at sea level. Since we did not know the pressure drop 
of the system at the outset, it was not possible to know the 
fan flow rate that would define the air exit boundar\^ con- 
dition. To get around this problem, the following iterative 
procedure was used: 

1, An initial fan flow rate was guessed. 

2, For this given fan flow rale, the flow field including tlie 
pressure drop was calculated based on the uniform exit 
velocity across the exit area that would result in the same 
volumetric flow rate as produced by six fans. 

3, For this computed pressure drop, the corresponding 
flow rate from I he fan manufacturer's performance curve 
was found. 

4, An average of this new flow^ rate and the previously 
guessed flow rate was used to calculate the exit velocities, 
which were used as new boundary conditions for the next 
computation- 

5, This procedure was repeated until the guessed flow rata 
produced the corresponding pressure drop according to 
the fan curves. 

Computations 

The three-dimensional Navier-Stokes equations of mo- 
tion' were solved in the nondimensional form. The solotion 
technique used was the segregated method.^ A separate 
linear system was solved for each of the lour degrees of 
freedom — three velocity components and pressure. Relaxa- 
tion factors^ used for the four degrees of freedom were 0.8, 
0.8t 0.8 for the three velocity cooiponents and 0.0 for pres- 
sure. To improve the accuracy and stability of the solution^ 
an upwindiog factor^ of 1.0 was used for all degrees of 
freedom for all computations because high velocity gra- 
dients were expected in the coarse mesh regions. 

Starting from an initial linear Stokes flow solution, the 
problem was run for five iterations using the segregated 
solver, resulting in the following solution or convergence 
errors for the four degrees of freedom; 

■ X Velocity: 0.0084 
« Y Velocity: 0.0074 

■ Z Velocity: 0.0038 

■ Pressure: 0,021, 

The FIDAP Laser's JVfonuol recommends that these values 
be driven to 0.001 when using the segregated solver. How- 
ever, we were not able to converge to values lower than 
these even though several other values of relaxation and 
up winding parameters were tried. 

After the initial five- iteration soiutioot a ne^v fan flow 
rate was guessed and a second run was made. The solution 
w^as said to have converged when the pressure error was 



less than or equal to that of the first run, 0.021 . The results 
of this iterative procedure are given below: 

TypicaJ FIOAP Run 

Run Number of Fan of m Pressure Pressure Drop Fan of m 

Iterations Guessed Error Computed Aotual 

1 5 H)(J n.f321 0,46inH;,O 7n 

2 7 85 O.OIG 0.40inH/3 90 

In this typical example, 12 iterations were required to 
find a value of fan flow rate within 10% of that actually 
sopplied hy the fan. Given that other simplifications in the 
model had been made, it was felt that this level ol con- 
vergence and accuracy was adequate. 

On the CRAY Y-MP supercomputer, 10 hours of CPU 
time w^ere required to perform the 12 solution iterations 
needed. Memory needed was 4.0M words of main memory 
and 67M words of secondary memory or scratch memory. 
For scratch memory, a CRAY SSD (soIid-.state storage de- 
vice] was used. This reduced an otherwise substantial I/O 
wait time penalty for disc memory devices to a small frac- 
tion of the total run time* 

Numerical Results 

As mentioned earlier, general flow characteristics in- 
cluding the velocity profile and the pressure drop across 
the system were computed. vSome typical pictures of the 
flow velocities through the system are shown in Figs. 3,4, 
and 5. These illustrate well the qoalitatlve features of the 
flow entering the CPU side and the I/O side ^t the top 
section, turning and going through the printed circuit 
boards, and exiting the fan outlet region. An interesting 
aspect of the results is that a substantial portion of the flow 
entering the I/O side or the rear of the cabinet actually 
passes over the backplane obstructioo in the top section 
and flows to the CPU side at the front of the cabinet It can 
aLso be .seen thai' the velocities are low^ at the entrance, 
increase between board slots and then decrease again at 
the exit of the board slots. The air velocities are higher in 
the four CPU board slots than in the memory and 1/0 board 
slots and are in the range of about 1 to 2.75 m/s. 

As mentioned earMer. simulated particle paths or traces 
were recorded on video. The traces represent the path that 
a massless particle would take through the computer cab- 
inet if released at various locations along the inlet planes. 
Such traces are very useful in giving a qualitative represen- 
tation of the three-dimensional complex flow^ field. Using 
MFGS» the Multi-Purpose Graphics System from Cray Re- 
search, these traces were animated to shcw^ the details of 
the flow. The animation very clearly shows the cross flow 
of air from the I/O side of the cabinet to the CPU side and 
other complex features of the flow. A typical picture of 
particle simulation is shown in Fig. 6, 

Experimental Results 

Experimental measurements of the air velocities were 
carried out on an actua] system with the help of a hot-wire 
anemometer. The cabinet walls and some of the boards 
were modified so that the hot wire could be inserted into 
the cabinet at the desired locations. Velocity profiles were 
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Fig* 7. Computed Bnd expenmenlai air ve!odttes in CPU 
board slot at the middle of the board. 

measured in the CPU and I/O board region across the 
boards* A typical velocity profile measured in CPU board 
slot at the middle of the board is shown in Fig. 7. The 
slot depth (X in Fig- 3), is plotted on the x axis while the 
respective velocities are shown on the y axis. It can be seen 
that the air velocities are in the range of 1-25 m/s to 2.25 
mis. The velocities are about 1.5 m/'s at both ends of the 
board, with the highest velocities of about 2.25 m/s in the 
middle of the board. One of the reasons for the nonuniform 
mily in the velocity profile is the presence of various com- 
ponents (chips, heat sinks, etc.) on the board. 

A comparison of the numerical results with the experi- 
mental results is also shown in Fig. 7. The numerical results 
predict higher velocities in the center and lower velocities 
near the ends than were actually measured. However, the 
range of velocities is about 1.5 m/s to 2.75 m/s, which is 
relatively close to that measured experimentally. It should 
be noted that in the numerical simulations, the board com- 
ponents were modeled as blockage to the flow, whereas in 
the experiments, the boards had actual components on 
them. 



Conclusions 

Steady, viscous, three-dimensional air flow within a 
computer SPU has been analyzed using finite element model- 
ing. General flow characteristics including velocity profiles 
and pressure drop across the system w^ere computed. Nu- 
merically simulated particle traces were recorded using 
video equipment. I( was found that numerical simulation 
of particle traces can show good qyalitaU%^e features of the 
flow through the system. The particle traces show some 
extremely inleresting flow characteristics that could not 
have been known easily otherwise. The computed velocity 
profiles through the boards and the computed system pres- 
sure drop have reasonably good accuracy. Modeling pre- 
dicted the air velocities through the CPU board slots to be 
about 1.5 m/s to 2,75 m/s whereas the experimental mea- 
surements show^ed about 1.25 wJs to 2,25 m/s. However, 
finite element modeling can be relatively expensive in 
terms of computation time. 
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